Les Amis d’Ethereum France #5 — Zero Knowledge @P2P Festival

hard to follow that, everyone. Philippe Honigman here. I'm delighted to welcome you tonight, both for the Peer-to-Peer Festival, whose first day it is, and for Détrouver en France, for an evening focused on zero knowledge. Originally, the person who was going to introduce you and who organized this event, Nathan, couldn't make it, so I'm replacing him. But thank you to him for preparing this whole evening.

A few words about Détrouver en France: we are a non-profit association (under the 1901 French law). We've existed since 2015. We are dedicated to [unclear - possibly "being reburied" or "being reburied"]. We are not sectarian or maximalist. Our main goal is to promote education and encounters.

We don't mean encounters around these topics. We have a website, été de france.com, where we publish quite a few articles and have also translated technical articles, Yellow Peppers, and many, many articles. And of course, we are also known for our events, so, Friends of the Terrains of France A session that we started, a series of sessions that we started a few months ago, this is the 5th one tonight, and then, as you probably know, some of the biggest European events around men's fields, which takes place this year in July, I'll talk about it again in a few moments, supports us for tonight, it's down there, well there you go, and a protocol and a token that aims to promote and financially support community projects on summer men's fields, there's an incubator, a French crypto project investor, it's a word, a samurai co-op that does video capture and video editing since now our sessions are published on YouTube in the days following the session, and finally XXI Amphorae which is a small seed fund, Treptow, the next events, there will be a summer friend in Rome in May, it's not yet defined, neither the content nor the date, we'll see here on Monday because if you want to talk about topics, there are often projects that present their content during these sessions, but it's also open to technical speakers on various subjects, so Don't hesitate to suggest content; we'd be delighted to welcome you. And of course, there's the fact that we're here, so I'll talk about it right away.

There will be 6.6 this year. It's in July, from the 19th to the 21st. It's even a bit bigger than last year. Three years ago, we were a bit limited by capacity restrictions due to the empty co-op.

This year, we'll be welcoming 2,000 people, the maximum we can accommodate at the Maison de la Mutualité. So, the whole ecosystem and Théréau are there, but beyond that, many people who come to Paris won't be at the conference because, unfortunately, we ca n't sell tickets due to venue limitations. But there are many events happening around the perimeter, and that's the goal of Letizi Week: to bring together as many events as possible. We're planning about a hundred events that will take place throughout the week. If you have any events that you're organizing yourselves, don't hesitate to let us know because we have a website called...

Here's week dot fr, which allows you to publish. By the way, there's a button on it where you can publish your event so people know where you are. I'm not forgetting anything about that. Yes, of course. And the next wave of tickets is on April 30th, so in two days, I think.

And to finish off tonight, okay, we'll start with Leo Cyrus, the 6MB site, to present Tornado Cash as a large-scale ZKK application. Then we'll have a presentation from Alexandre de Consensus on the qualifiers, and finally Henry, if he arrives on time. He hasn't arrived yet, no, he hasn't arrived yet. So if he arrives from Amsterdam, wait, he'll present the state of the scales of beings. Carole, hop, we laugh, Liautaud, two stars, what?

There you go. Thank you very much for being here. And now I'll hand it over to Leo. Hello everyone, my name is Les Hauts de Six Mots, and I'm going to show you a little bit of Tornado Cash. So Tornado Cash is one of the only examples.

It makes One of the few 2.0 Knowledge examples that are actually in production is very interesting because it's something that really works and leads to very concrete user experiences. So, on the other hand, you had addresses and could make transactions to send Shadow Ether. To simplify, we have 0 x 1 and 0 x 2, and we want to transfer 1 and r. The particular problem is that if these two addresses belong to me, as soon as I send this Ether, I will create a direct link between these two addresses.

For example, if 0 x 1 is my main deposit, so it's my bank account with all my money, and I send Ether to OS X and OS X 21 6MB dot E, which is my rather public address, I will directly link these two addresses, and everyone will be able to know my identity for the rest of my life. So, this is what we call being hacked; it's about revealing your identity behind it. So, here, OS X 21, we can clearly see that it's me. But I could have an anonymous account, for example, and I would reveal it directly. It's between my different accounts, so that's exactly what Tornado Cash is doing: finding a solution to this problem.

So how could we do it? And to find this solution, there are two possibilities: either there's an exchange, so in fact, we'll send money to 0 x1 on, for example, 1 year ago, and from 1 year ago we'll send it back to 0 x2. So that's what we call privacy custodianship. It's privacy that is very restricted by 1 year ago, for example, and in the end, it's not really privacy since they know exactly all the exchanges that are made. The second solution is to use a mixer.

So a mixer—it's going to be a name that means private social media. If that's exactly what Tornado Cash is doing, it's because it will live in a decentralized, independent way as a smart contract on the blockchain. That's what the documentation announced. That is to say, in the summer of 1991, Rome celebrated the six solutions that do both. So, if I take my example 20x1, where I want to send one ether to x0x2, we'll try to see how we prefer to do this.

So, going through a contract, we'll have two functions: one function will be two deposit requests. We'll deposit one ether from the first address, then we'll make a withdrawal from the second address. The problem is that we 're thinking, "Well, everyone can withdraw one," but that can't work. So, we'll try to think, "Okay, it's the same person behind it, so we just need a secret." We'll send this secret as an argument for the deposit and use the same secret for the withdrawal.

That's the most naive way that comes to mind, but by doing this, we immediately follow the logic. This is because all the links are public, and we'll immediately see that the secret comes from x0x1. So, in fact, this doesn't provide the solution. The second idea that comes to mind is... The idea is to say, okay, we'll release it, we'll go to the secret, and then in the withdrawal function, we'll check if this secret corresponded to the same thing we know, because it's because for them, it would be enough to have noise from forces and through all the ages that have been deposited with all the secrets that have been used, we immediately see the links, everything is public, it's very simple to make it shine, so we feel that the architecture there corresponds to something, but we need a technology, something that would allow us to prove that I know the secret that allowed, that allowed, that allowed to do the TPO.

In fact, that's exactly where we're going to use the heroes. Knowledge proof is long, it allows us to prove that we know this secret but without ever revealing the secret. In fact, we're going to prove that we know a secret once, and it's worth the value that was deposited in the contract. So we're going to go in a little bit, we're going to see a little bit, so the roles, and I prove what it is, it's going to be, that's what we This calls a cryptographic system that allows a proof to be generated from a prover to a very fire, and this very fire will be able to verify it and be sure that this proof was indeed made. So it would attempt...

There are three properties behind its match-pose appearance: they are linked to completeness. This means that if the prover makes a proof honestly with a true fact, an honest very fire will be able to verify this proof and say that it was indeed done. The other way around is tiresome. If the prover tries to cheat and prove false information, in fact, you will never be able to pass. Fire will roar.

No, the heroes of knowledge... This is that this proof will not contain any concrete information about what we want to prove, the arguments that were used to prove it. So, if I summarize a little more, let's say in a more concrete case what this means: it means that we will be able to execute code without cheating in the execution of this code, and in addition, the content of the variables that will be used in this code will be completely private. So, in fact... to deport this execution without ever revealing what happens inside, but the very fire that will verify the proof, in fact, to be sure that the result is the execution that went as planned, so if we go back to our previous case, we wanted to prove that we know a secret whose h is known and that inside it are hours, we will release this secret and verify that the result corresponds to the known purchases, so in fact we will enter the secret, the secret will be what we call a brave and input, that is to say, it will not be used on the verify hours side but only on the prover side, inside the prover we will redo the h and we will verify that it corresponds to the ages of the secret, so what is in white, we find it on the verify hours side, so it's the same data and the Rifai lift manages to tell me yes or no, we could be more concrete about what happens in their time in Tokyo, in fact the proof will run in order in the browser in JavaScript and the very fire It's going to be converted into smart contracts, so something solid here, and it's going to be in smart months to call with the professor as an argument who will tell us loudly about the proof in front of the public, a beam that we typically give her, the HB of the secret.

In fact, if we come back here, we managed to predict that we succeed in making a withdrawal by clearly proving that it was us who made the deposit because we know the secret that praises secrets. The problem is that in the end we fall back on the original problem where we know since we need to inject the secret. So in fact, we're from Auxerre and we've made a little progress in the logic, but we're still on the same problem. We haven't solved the original problem. For that, I need to present the marquetry.

The marquetry is a structure for the integrity of the whole dataset and which is inside the Halperin mark and which will also allow us to prove very Easily, part of this date is right inside its mother, which sorts the games. Let me explain precisely how it works. So, in fact, marquetry is a tree. There will be leaves and a path, which is the tree's path. We'll start from all the leaves and go to h, and so here I'm talking in binary marquetry, in a binary way.

So, the node above SARP is between the h of L1, L2, and the h of L3, L4. And then we'll repurchase the result from the two nodes until we reach the path. We're on the path. So, in terms of integrity, let's imagine I try to change L2. So I put a high value for L2.

What happens? The h of L1 and L2 also changes, and therefore the hqe and reused above also change. So everything changes, and the path is modified. So, this clearly shows that for each calculated path, all the leaves have values ​​that were calculated during the construction of these marks and the sorting. Now I'm going to show you how we can prove it.

Let's say we're part of Katherine's tree. Imagine we want to prove that leaf L3 is part of this tree. So we know L3, so what you need to understand is that this information is published somewhere, so everyone can go and find the data that interests them. So here I'm going to take L4, and thanks to L4, I'm going to recalculate the h of L3 and L4. So I'll have the value I calculated myself.

Then I'm going to take the h of L1 and L2, and similarly, recalculate the h above. And that's it, I've gone back to the route. So now I can compare it with a route that will be published to see if the result matches. If the result matches, I know I'm in the right place. If it doesn't match, I've cheated.

L4 isn't actually the four of them. So what we call the mayor, which she passes through, will be a table of elements that allow us to go back to the route and prove So we're definitely inside, so there are two elements, the two circled elements. I made another example with a slightly larger tree, so here we're going to try to prove that the cat is part of the tree. We need l3 to recalculate node n 34, which is therefore h2. l3 l4, we need them, n 12 for the calculation, n is above, then we need the other side of n 56 francs 18 to recalculate the août.

So there you have it, the Merkel tree, because I correspond devices, only has three elements: l3, n 12, n 56, 78. And in fact, what's very interesting is that we could have naively asked ourselves, " Why do all this?" We could have simply done a check, the sum of all the leaves, and the result of the Czech check would have allowed me to ensure the integrity of the tree, or rather, two of the leaves of the data. Yes, but to prove that we're part of it, we would have needed all the leaves to build this check scene. And to verify this, we only need three elements.

So, in fact, if we generalize to the Aisne level, we'll have two powers of n leaves, and our proof, as we see with three elements, is a look 2 of the number of leaves. So, we had three leaves, so actually, 8 leaves, we had three elements for the proof. And where it gets interesting is that if we have a thousand leaves, that corresponds to 10 elements, therefore 10 levels, and if we have a million leaves, that corresponds to 20 elements. So, we'll only have 20 hours to prove that our data is part of a million other data. So, to recap, the route guarantees the integrity of the tree.

The route is short, which is very practical in the Blue Jays since we can store it in a smart contract, and we only need the base-2 logarithm on a binary of the number of leaves to prove that we are part of the tree. So, if we go back to our mixer smart contract that we are trying to create So we're going to try making some space and we're going to try to say, well, actually, the secret's hb that we saw, we're not going to store it directly like that in the smart contact. We're going to build a marquetry in the contract and we're going to take the most... let's say we're going to add a leaf, so we're going to take the one that's free, or the part I mean, so that means there's a... the first leaf was used, we're going to put it on the second leaf and so we build this tree, we have a route and we're going to use this route in the zero-knowledge...

by doing this, what's happening is that we're trying to prove that our secret, once h, corresponds to a leaf of a tree, and thanks to Merkel passes, we're going to be able to re-verify in the zero-knowledge proversor that this leaf is part of the entire tree, and so we're doing a proof of number chip, we're proving that we're part of a set. Here I'll go into more detail about what the circuit provers correspond to, so that's what's happening... Inside the prover, we take the secret, we enter it, we go to the [unclear] with all the elements of the mark, it passes, and then we do what we call a constraint, that is to say, we will constrain this result with the route that was calculated. Here we have done a proof that we can leave secret, and that this secret was a leaf, and that the leaf is part of the tree whose route we know, and therefore the route is the real route that is in the smart contract. If we go back here, so we have in fact solved our problem of being able to make our withdrawal.

Now we have a second problem: we have 1 infinite withdrawal. So in fact, we can withdraw as many times as we want because each time we can regenerate a proof to prove that we are part of this tree. So we could say, but we could just store the result of the proof in the contract, which isn't wrong, but in fact, only the rest of the proof is quite large, so it's difficult to store, and in addition, there's a peculiarity: we can cheat a little. Over time, what this proof looks like and the verify function will always say it's true, even though we haven't changed the input arguments. So, in fact, we're forced to add another type of argument, called a null if elsewhere, which will be injected at the zero-knowledge proof level to be able to store it in the contract and say, "OK, this withdrawal has already been made."

So, these nights, elsewhere, we could say it's a bit like a ticket; it's a ticket that we're going to deposit once and that we're going to check if it's already been used. If it has been used, well, too, so we can't withdraw it. If it hasn't been used, we can withdraw it and we store it. So, the problem is that at this stage, the null if elsewhere, we can come with anything. So, in fact, we can take any random number, and in fact, we need to prove in the zero-knowledge proof that this null if is valid.

We need to prove that this null if was part of the original deposit. So, we're just going to... In fact, we're changing the secret's homebrew in the repository, and we're also going to add the nüvi fire. So, in RE4, there will also be the nüvi fire, and when we manage to do this proof, we'll do it with nüvi fire. So the circuit changes a little.

We end up with just the nüvi fire, which has injected the secret this time in public. And so, we redo the secret's homebrew and that of a leaf elsewhere. We check the mother to make sure it passes and we trace back to the routes. If we do a quick recap of what we've seen, we choose a random secret, so with as much entropy as possible so that it can't be too strong, and everything is public. We also choose a random number for the nüvi fire.

We call the lease function. The secret of a leaf is elsewhere, and the lands we send the contract to will automatically be sheltered behind everything the mayor sorts directly. Unchained, we wait, so why do we wait? I have n't spoken until now, but because in fact, here we have what we call a ring. Is it anonymity 7?

That is to say, as I told you, we do a proof of the chip number of a meerkat rit, so of all the leaves of the merkel tri. In fact, if we don't wait, we can very easily guess by statistics and attack that the person who just withdrew is very likely the person who just deposited. So what Tornado Cash advises on their official website is to wait at least 24 hours, but the idea is to wait until there have been as many withdrawals as possible before making your own withdrawal. And 7 anonymity, this island is made up of all the people who have used Tornado Cash, so typically, we're talking about it on a controller. It's the turn of 50,000 people, but also time, in fact, that we'll wait before making the withdrawal.

If we wait, we'll add another week. It's totally safe, it's impossible to... there are so many possibilities that it's impossible to guess the link between the two addresses. We waited, generated our zero-knowledge proof, and then we can call the withdraw function. With laser knowledge proof has become different, so thank you for this and for listening.

And in fact, we're recruiting, so we make mistakes, and I chuckle. If this word is a protocol attestation, it means that we're going to attest to facts on contracts in the field. In fact, these attestations will be either public or from zero-knowledge sources, which will allow us to avoid making links between the addresses we use for the facts we want to test and the one we were using and the one on which we put this attestation. There you go, thank you very much. [Applause] Do you have any questions?

Yes, good evening. So, Gene Tic and they're a little bit of a troll here. We're dealing with some issues. Regarding privacy, wouldn't it be simpler and more widely used to have technology directly designed for privacy? I'm thinking of my hero beings hiding this kind of thing rather than using protocols that are quite complicated for the average person.

So, what you're saying is that it's more interesting to directly use Z-Cash, which is actually a blockchain that uses Knowledge Proof Heroes at its core, than to use and Rome, which is public by nature, and add the contract? Is that right? Well, I disagree because, in fact, we're blocking the user. That means we're only going to use seven blockchain blocks to do its function. That is to say, we're shifting all its usage onto seven blockchain blocks, whereas this kind of special case allows us to add another functionality to the fields.

I see why we're preparing to add this functionality, and here we're on a Tornado Cash exodus, but Knowledge Proof Heroes is actually a much stronger technology, and I think that in the In the next ten years, it's going to explode, and in fact, we'll be able to have a huge number of new types of applications that will be made directly on smart contracts. The Wii is very simple, so right now we might say, "Okay, you're hiding something interesting," but tomorrow we'll have decades of much more complex applications. What we do with 6 MB is already more complex than that. We'll test things, we'll do 2.2 MB tests, lots and lots of things directly.

We'll prove that you have crypto, that you have guests, that you have things like that. So, I don't think it's Aulas who's failing to do anything about this cache. My answer is, is there another question? If we tell the person not to withdraw before 24 hours so as not to link it to NATO, that's a very good question. The HC documentation is really used to move money to us, between our own addresses.

It's really not made to send money to someone. Because, in fact, the most concrete use case is really... I have I have ten addresses and I was moving money from one address to another. How do I do that? It's Louis.

Imagine another app, it's cool. I just have a question about the amounts. Once I've made a deposit of a certain amount, the withdrawal finally needs to be split. I know, very good question. So, in fact, the withdrawals and deposits are always the same amount.

That is to say, the marquetry I was talking about will actually be all the deposits of 1 and r. And so what ADO Cage does is that there will be several groups: 0, 1 and r, 1 and r, 10, 100, and we have to go to one of these groups. They released a new version not long ago called Tornado Nova. It's in beta, it hasn't been audited or anything, but it allows you to make deposits and withdrawals with a much more complex system. without having fixed amounts, and it actually uses a technique and technology very similar to this cache behind Kir and implemented in these zero knowledge and poke, so there's no question of sending money from one person to another.

Is that what Steak does with their two situations of seven cases are pink, therefore Aztec, they do, therefore Aztec, they go very, very far in the air with knowledge, they are the ones who notably released new zergs at the rhythm like Plomb Plus Cup etc., and they created Zykë in Monet, and in fact, they allow precisely with the relay two, so it's a better 2e where we will send money on it and we will be able to transfer between people directly, still in the zero knowledge, so we will never know what is happening, and there we are a bit like in Z Cache, so in fact all the exchanges are private, so we can make many exchanges between many addresses and then we will be able to retrieve them on momentum and withdraw them to our address. Yes, is there another question? I wanted to know if we want the interface with another contract, what is the cost for that contract? How much does the Tornado contract cost, or the Verify Hours contract from Zero Knowledge, the Very Scrap Hockey contract?

So I have the mattress, so we're talking about that contract, actually the Verify Hours contract from Smart, 12 hours of knowledge. So it depends on which technology uses it for the one generated by a platform with Circum and Snark JS, which are going to be a whole toolkit for making knowledge heroes. We're around 250,000 gas, so that's a lot. For an order of magnitude, in fact, a transaction is 20,000 gas, so 105 in 2000 is really the low end, and as soon as we add several public INHP ​​tools, we quickly go up to 300,000 or even more, so that's a lot. So thank you very much, thank you.

[Applause] Hello, so the presentation has started, sorry my computer could n't share the screen. Yeah, okay, so What I'm going to present to you is what we call Egypt, which I imagine many of you aren't entirely familiar with. Renault is a bit of a loose cannon, and the talk is rather technical. I'll try to go slowly and not get too bogged down in the details. And if anything goes too far, don't hesitate to interrupt me or raise your hand.

I think that will be better for everyone. So, what a girl who likes it is, it's concretely a cryptographic tool. As you may already know, it's been re- operated to support what we call smart contracts. In a few words, this means you can deploy a program on the sanitary blocks and man that will specify how several people can interact with each other. So, for example, this is how we can specify bath times, swap contracts, or NFCs.

These are also initially smart contracts, and so this evening of contracting does its challenge on a virtual machine called a VM, or could be a field of Virtual machines are the whole point for ICS and IBM: to build tools and cryptographics that allow us to prove the correct execution of transactions on the incoming i's. So, how does it work? I'm going to present our approach to doing this. There are other projects doing this; I'm thinking, for example, of this technical role. Singh Herminis Aztec is also working on virtual machines, but with privacy support.

In our case, that's not really the case for the uses. The use case for us is simply based on an observation: a proof is much, much faster to verify than transaction executors. So, it allows us to greatly improve scalability in a given environment. But if today the internal network is capable of processing 20 transactions per second, we think that with this kind of technique we can manage to place several thousand transactions, and we think that, not directly on Terium, but... On what we call the best of its kind, another point, but the next talk will delve a bit deeper into that, so I won't elaborate much further.

So, more details: it's been a little over six months now that we've been working on the design, implementation, and specification of Nikkei's Dit M. It's a rather technical challenge, as you'll see, and tonight I'm here to share with you all the progress we've made. So, you should know that there are several approaches to building a Zik FM. Without going into detail, these two approaches are: in one case, you build a virtual machine that works extremely well with proof systems, and as a result, you get something quite efficient, but it's not directly compatible with how Ryom works internally. So, this leads you to develop transient systems, and that's what Zykë Sync does, for example, with its Ding language.

It's also what Quaero does with its own virtual machine, but other projects developed by NetherRealm are working on Lever's transient system. In their virtual machines, there are other approaches that consist of directly trying mules, the VM in proof systems, and specifically targeting the VM through what we do. So we chose the second approach. So how does it work in broad strokes? In fact, let's see what it looks like in the case of a role.

What is a rollup? In broad strokes, it's basically what we call a rollup. What you do is that you send your transaction not directly to iTélé, but to a client, what we call a client rollup. In fact, the interface with which you do it is more or less exactly the same as what was done in Riom. You can do this in RPC.

The happy Loeb, firstly, sequences the transactions, meaning it will build the same thing as doing a block. It's simply doing a large batch of transactions executed at once. Then, point number 2, these transactions are sent to a slightly improved virtual machine in which we have Thanks to these tracing features, we obtain a great deal of information about the intermediate values ​​taken by all the registers of the virtual machine and Terium. This allows us to, and this will be very useful, use the raw material to build proofs of correct execution or integrity of calculations, to use the French term. Then, once that's done, its process is handled by another module that will perform what we can call data organization and expansion work to obtain large datasets, making them easily verifiable.

Once we have this data in this format, we can feed it to the Asian provers so they can create a proof. After this proof, you can verify it directly on the network and Terium, and it will cost you much less than if you had to verify all the transactions at once. Sure, it's here! So that's really the usefulness of this system. So, a few words on the structure of this system.

The proof is that we've essentially disassembled the virtual machine and Terium in a theoretical sense, and we've identified many components that make it provable in a certain way. So each of these components can be seen as a sub-virtual machine, and we prove not only that it works correctly but also that it has worked consistently. This proof of consistency is done using what are called proofs of inclusion. I won't mention this during the questions, but basically, it's a proof system that was initially developed by the Aztecs and is extremely practical. It allows us to prove that a vector is included in another, meaning that it contains all the same values, without counting repetitions.

This allows us to do many things in cryptography and it's incredibly powerful. So, if we zoom in on one of the rectangles, we have a sub-part of the execution path. So here you have a sample of all the data needed. In practice, there's much more, but here you just have a few sub-parts of the cost. From what the execution trace can contain, you can recognize, for those who are quite familiar with the operation of a CPU, the instructions that are executed.

You will find other registers, like the PC, which is in the program, what we call the Kunter program, and you can also find a number of pointers, in fact, Happer Respect WSB. In fact, this allows us to model the stack, and so these are there to answer a technical problem: how do we represent an obstacle to knowledge? So it was a small technical challenge to do. So there you have it. So, if we go back a little, for each of these directories you see, we have a matrix like this, and each one is...

what's there is that the columns of these matrices must satisfy arithmetic equations between them. That is to say, at certain times, we must find a value in a column to the left, it must be found one step higher in the column to the right. These kinds of constraints... All of this is specified in a document that will be published in full in June, but we already published a part of it in March on Research. It describes exactly how we have these constraints, what the columns must represent.

Of course, you're only seeing a sub-section here; in practice, we have several thousand columns, the result of a long-term project, for a total of over a thousand columns. So, in the specification, as you can see, we define ourselves as follows: you have `if` statements and `hell` statements that determine if a constraint should be a force. Once you arrive at the desired result, you know which constraint should be a force. Through this set of logical rules, we can represent whether this corresponds to an integral execution of lever m. So, if I give you this and you verify all the equations, you can be completely convinced, without ambiguity, that the trash you see corresponds to a totally integral execution of lever m.

Therefore, to describe all these constraints, we used an arithmetic tool. So you have what allows us to encode all this logic of ifs and elves that you see in the room in the previous slide, but also other things. We can also add constraints such that certain columns must contain exactly the same elements in the same number, but not necessarily in the same order. These are called "fling rocks." You also have what are called " kairos" (time of Kai Reus) and virtual machines, which is developed by Starck.

We borrowed their idea of ​​"red roof," and it's a great find. It allows us to prove that a value is very small, and typically it's called... It's very useful for proving that a value is between 0 and 2,156, and it comes up pretty much everywhere. Also, by using what are called... younger designators prove...

that is to say, we use... to link... to prove the consistency of modules with each other, but also to represent all the logical operations that are not easily representable with arithmetic equations, like... the... of...

well... For all these kinds of things, we use specific systems, like Pelloux Cup, and so we also have a whole pure system for all the additions. We also used techniques called " splitting" because, in fact, the numbers we work with in the cryptographic proof system belong to what we still call finite numbers. And without going into details, it's not the same as the words of the virtual machine, which are 256- bit words, and that's due to the complexity. It means that a word of the internal machine is smaller than a number that we can use for the KHL in cryptographic systems, and so we need to split it in two.

So there are a certain number... I already mentioned that, but for the stack, we had a number of challenges to overcome in order to represent it. We also had to represent a stack in a wick, approximately - the edge. It's quite complicated in itself, but in addition to that, you have to know that the virtual machine allows you to do operations like... to pick directly from the bottom because people are familiar with what a stack is here, I might explain a little, basically in a processor there is a memory area that allows you to pick from it, which actually serves as a pickaxe, and two working areas that the processor can access directly without any delay.

And in the Deuterium virtual machine, this is represented as a stack. This means that you can only access the last value, theoretically the one you added. And it's a somewhat special stack in the land stack because you can also swap elements arbitrarily between the last position and the 32nd, for example, but any position between 0 and 30. You can also want to access many elements at once, in a pop-up and huge way. The idea is to remove a huge number of elements from the stacks all at once.

So, to be fully compatible with the virtual machine and Terium, we had to do this. We represented all of this using a pointer machine system, which you can see here. This part is included in the Mayenne execution fresh, meaning the central module you see here. Through a whole set of pointers, we manage to represent what we call a spectral stack, which never actually exists as such in the tables you see here. We only see panthers pointing towards this spectral stat.

And through the entire set of constraints, we ensure that this spectral tax is always respected, even if it never exists as such. This demonstrates the struggle with the proof system. So, a quick word on how we assign the columns: as a reminder, the way it works is that we run the transactions directly in a virtual machine. This virtual machine was real. The actual system gives us a lot of intermediate data that you can see, for example, the instructions in the Kunter program.

But to be able to apply our proof system, we needed to build many other columns so that everything would be probable, and that's what we call generating auxiliary columns. So, this is something we were able to implement. Below, what we have today is still a project in progress. However, what has already been completed is that we are now able to actually run transactions and obtain the columns. The proof system is still being designed and implemented, but it will be very soon, probably later this year.

So, for now, we have nevertheless been able to run Unis, either on our own or on our own. Another point about the implementation is that all these constraints, as I told you, are several thousand. In fact, to implement them, we built a library that allows us to describe them in a language very close to that of the specification and to generate all the arithmetic equations. What we need to achieve our constraints is to ensure they are met. This will be very useful for us because it will also be used to audit the stack and provide formal proof.

So, what we're missing is... well, we did a demo last week for practical reasons. I won't be able to do it today, but as I was saying, we were able to compile a story with Truffle, run it on the IBM server, perform swaps, generate all the columns you saw from all the modules, and verify that all the constraints were met. What we're still missing is a few SSE instructions and the Earth, Lery, and Green lines. This is what happens when the smart contract is reached and invalidated; the transaction must be aborted.

In this case, there's a fairly complex stack management system; we 're still working on it. There are also what we call logs or events. We'd like to be able to prove that an event has been successfully deployed; it's very useful. In many cases, two types of land use today, it would be a shame not to see that, and also company loans, comprehensive loans, that's what allows for very specific operations, most of the time it's cryptographic operations on land. Human use cases are a case of, for example, strokes, where we could prove a life, whether it comes from a music company or IBM or things like that, or verify any time layher in an IT services company that comes from...

so we're also missing the part of generating the proof to verify on the state of Rome, and that will be for later, and we're publishing the complete specification of our VM ticket. So there you go, sorry, I know it was very technical, I did my best to simplify as much as possible and remove all the unnecessary details, but if you have any questions I'll gladly answer them. [Applause] Thank you, I have the impression that their pace and ISA SION is artisanal, it's their favorite, and that it's not systematic, it's... Saying that if we look carefully, we'll find cases where you think you've proven something, but in fact, I executed something else. Oh yes, that's right, it's not enough to show equations to say it works.

If that were your point, we work on proofs, on formalizations, on what we call formal proofs, and the challenge for us at that point is where—well, I'm saying it—it's definitely work on formal proofs for our pace and structuring, and the whole challenge would be to prove that for every execution trace, there is only one valid execution path, to lift m, and all that. It's all a lot, indeed, it can't simply be one of their favorites as you say. Yeah, and, and it's called, do you think this proof is possible? I think it is n't. Stark were it for that, VM Quaero, and we have teams of formal proof experts working on it to formally verify the VM that also work on it.

Rhyme 2, I think this kind of thing is within their reach, thank you. So I have two questions. The first is, what's the difference between AKA Hero and Easy Cash? With Quaero, can we only run Stark scales, or is it because CAI is designed to be as efficient as possible with music and Stark? To my knowledge, I don't see any theoretical reasons why we could n't run Quaero with something other than the Zykë Stark system.

One difference, however, is that the structure, the architecture of the Quaero virtual machine, differs from the Deteriorate virtual machine. Both machines are Turing complete, which means that in theory it's possible to work with one another. And in this case, Naisseur Man, which is, if I'm not mistaken, an internal .NET client, works on a transponder of solid tools towards the Quaero BM. So in the end, it means that it's possible to compile a smart contract once that...

once that... It works, it will be possible to sweat a solid contract and winter the Quaero VM, but not directly to deploy a contract compiled with Truffle, for example. It's simply this small detail that changes, okay? And a second question: have you already had benchmarks of the execution time of proofs and everything on Zik and VM, or is it just now the specification? No, for the moment, it's simply that we are mainly working on the specification.

We will have these kinds of benchmarks when we release the proof system. In the end, okay, thank you. Today I have the impression that we have six, seven, eight, and IBM between Polygon and Remedies Si Casting, and that's why everyone is working in their own corner rather than doing like 'rotten' Terium and working all together. I think, to my knowledge, we don't have such close collaboration between the different projects and Remedies Crawl Tech Stark. Yeah, Si Casting, who, and I'm forgetting a lot, but even so, I find that in fact there is a rather good collaboration, and when we published a sample of our spec, we had a huge amount of Feedback from Scroll Tech also comes from Star Wars engineers who made suggestions on how to improve the design.

So, in fact, I think that's more about collaboration. There was a logic and VM meeting in Amsterdam last Friday where we all met, for example, and collaborated on how we could improve the processing of the HP function for each system in proofs. It's not a one-off; we don't send messages every morning, but we collaborate. One last hello. Two superb presentations already, and I just wanted to ask where we could find the article and the full code, or at least the source code, when it's published on the 14th.

So, it's to be published in June. The total specification with all the equations will be published on the same day. Norman has already published a technical report which contains, to say the least, a description at the level of everything, much more detailed than the presentation, but which presents all the general ideas that we applied to each sub-part and details a Sub-components, I'm not entirely sure which one, but you can find that one on research. The name is from the past: ASIC and IBM specifications. Thank you, hello.

You can hear me correctly, cool. So, thank you for being so kind and for giving me some of your attention. It's rare to have free brain time these days, and I'm grateful for the time you give me. My name is Henri Blot. I work at Star Runners, and my job is to do e-learning for stats.

My job is to explain to people what these Star Runners are and how they can build cool things on them. So, if you want us to talk about cool things, and me, and me, tonight I tried to talk to you a little more generally. I'm going to talk about professors, evidence of what has been known, the disclosure, how they have without the services so far in the world of the blog chain, what we are building with it, and what we can imagine. It's more about popularization. I'm not going to talk too much about mint, if ever If you have any questions, feel free to ask them.

Afterwards, I'll be weighed when the conference is over. I can talk like this, okay? You can hear me, Toussaint, with the microphone, pretty cool. So, first, let's talk about what proof of disclosure actually is. I'm going into too much detail because I think it was presented a bit in the previous presentations, but basically, it's a mathematical theorem.

This is for celebrities, not for brands, but it's something like, "Wouldn't it be amazing if I had an equation with a million factors and I could prove to you that I know a million points where it equals 0 without you having to calculate the 1 million points with the 1 million factors?" That would be amazing! Is it useful or not? Actually, it's a mathematical thing, for mathematicians, but like many things, building something on top of it takes time. So, there are mathematical theories where, basically, you prove that you know a Mathematical information without the person opposite needing to do any calculations is therefore a fact.

If you're somewhat used to using blockchains, for example, you probably have cryptographic tools in mind that you use quite regularly, such as hashes or signatures. These are mathematical tools; you know, there's math underneath. You know that if you want to dig deeper, you can. You don't have to understand the underlying math in great detail to be able to use them. It's a great zero-disclosure test, and the calculation test is pretty much the same thing.

In fact, you can see it like this: it allows a person, Allison Badia, to write a program, execute it, and get a result. Then, they send the program to a colleague named Bob. The result is what we call a proof of execution, and Bob can verify that the program executed correctly and gave that result without having to execute the program itself. It's something that can be cool. For example, imagine you want to do something Generative art, and on your machine it takes time because there are a lot of calculations to perform, and you send it to Alice, a supercomputer.

She will execute your program, prove to you that she executed it correctly, and you will be able to use the result without having to run your program yourself. In fact, it saves you time. The reason I have the same depth is that it's because in blockchain blocks, you have to see that it's pretty much the same thing. In fact, it's conceptually a bit the same thing: a calculation has been done, and you have a way to verify that this calculation was done without doing it yourself. When you look at a Bitcoin blockchain, you know that there is a certain computing power and a certain amount of energy that went into generating that block, but you don't need to generate that electricity.

It 's a bit the same concept, except that here you can do it with complex programs. So what happened? These are theorems, in fact... are relatively recent in the history of cryptography and math, and the first thing that came to mind for the people working on the blog chain when they discovered these protocols was... it's too good to be true, we're going to do things for privacy.

In fact, the first thing to happen, for example, one of the first applications that was really widely used was cache. The idea was to run a program, you're going to prove to someone that you're using something useful, e.g., OCS, which is good in the tool, e.g.

, the seven young people remain. I'm using a bit of technical jargon, and don't hesitate to ask questions. Afterwards, you can use an OK tool in Excel, you prove that you are the owner of seven successful uses of this tool, e.g., above.

You prove that you're not generating money out of thin air, and all of this you do on your machine. You only derive proof that you did something honest. You send it to the rest of the network that connects to... well, yes, it's true, he did something... Valid, I don't know what it is, but he did something that's valid and allows you to send money to people without everyone else knowing who you are or who you're sending it to.

A really interesting application, but it's not the one we chose for the beginning of what we're doing at StarQuest. It's not the main topic most people are working on today. There are projects working on loan solutions, but today the focus, when you hear about 10 km², Zikiro, the OP, is not at all about scalability, not at all about privacy. In fact, when you hear "roll up" indicated, for example, we quickly think, "Oh well, that's cool, anonymous." That's not the case at all.

"roll up" indicated it's not made to be anonymous, and you're not anonymous on it. It's important to know that. So, the second thing that comes up, after we've said "cool" about privacy, is scalability. How is it... What do we do to allow blockchains to handle more transactions?

Because there's this strange thing—I don't know if you've ever wondered—but Bitcoin, at just under 15 years old, was like this. A little less than 10 years ago, around the same time Bitcoin and Rome appeared, we had credit card systems with IP addresses, and they took off enormously in France. You have Vein, you have Lydia or Punk, and these kinds of systems can process hundreds of thousands of transactions much more easily than the Terrors. But how is it that Bitcoin uses these technologies, which are much more recent, since they shouldn't be more efficient? At the heart of this issue, why aren't blockchains scaling today?

It's because they use a security model that's different from that of your banks or your credit card processor. When you make a payment, there's a computer in the middle that controls everyone's transactions. When you make a transaction internally, it's controlled. by all the network participants, and you already have an instinctive understanding of why blogs and blockchains cost more. If I ask someone to do a job, or if I ask 10,000 people to do a job, it will inevitably cost you more if there are ten, ten thousand people—excuse me—doing the same job.

In fact, we quickly tend to say that blockchains are distributed Ledger systems, but it's not at all about distributing replicas. In fact, everyone does the same thing, and that has a cost. So the question arises: well, this is also a cool property, the fact that everyone verifies what's happening, that everyone trusts the system, that you don't need to sell yourself. Why are blockchains so popular? It's an interesting property, the fact that everyone can be sure that what's happening is happening correctly.

But the idea would be to ask ourselves, well, how can we make it so that everyone feels... art and executed the same work, and that's where zero-disclosure proofs can be really interesting because, in fact, if you take a network like BSC for example, what did they say? We need to do more transactions. They'll just ask the network participants to do more transactions and have bigger machines. The problem is that it doesn't work very well in the long run because the more you ask of each network participant, the more you exclude participants from the network.

For simple things, it's easy when you have a machine in the cloud to double its RAM, but not so easy with your phone. So, if tomorrow you can run one of the blockchain blocks on your phone and it grows in the same month, it's going to be a struggle. And so, this strategy does n't really work; it always ends up excluding the participants who are on the fringes of the network, and we find ourselves in the same system as before where there are a few computers that circulate the network for everyone else. The advantage of scalability systems with zero-disclosure proofs is that we... What's called a validity roll-up is that it allows you to delegate execution to certain specialized participants in the network.

It allows you to say to certain people in the network, "Hey, you're running a supercomputer very well, I can verify that everything you run on your supercomputer is correct. You didn't cheat because I can analyze the proof you sent me." So it wasn't based on trust in the person, it wasn't based on game theory, it was based on mathematics, and that's something fundamentally new. Suddenly, we can afford to truly distribute the work. We can afford to say that there are some people who will run the roll-ups and others who will just verify them and be certain that they They're not made to mess around with how it works technically and errors, but today it's a piece of cake under Stark Net, or in fact, the ICI roll-ups as a whole.

If you have a machine called the prover that processes a bunch of transactions and proves that it processed them correctly, and this proof is then sent with a state difference (green and errors), and all participants can verify that the state difference is validated and that the proof is also valid. I was going to say something, and then I forgot, it'll come. So now I'm going to try to give you a little overview. Now that I've laid out a bit, what is it, indicated by Valérie Turlock, what can we do with it, and if we see who does what, more or less, then the first debate you'll often see is Stark versus Snark. Personally, I think we don't care about that because what will count is going to be...

The ecosystem will have the most interesting applications and the most motivated people. What matters in a blockchain network is the community, the people who use it. Whether there are stars or snacks underneath, there are cool properties, but that's secondary. It's still interesting to talk about it, so I'll talk about it a little. There are two things I haven't mentioned.

The first thing is that if I run a program and give you the proof for you to verify, why is that interesting? Because verifying the proof is much simpler than running the program itself. In fact, it's even better than that. The more complex the work, the more complex the proof is to verify, but it scales logarithmically. In other words, the more work you do, the lower the cost of verifying the proof per unit of work time becomes.

That's why you have this somewhat magical thing called validity. The thing is, the more transactions there are, the more expensive they are per user. It's crazy, isn't it? In all other networks, the more transactions you make, the more expensive it becomes. The inverse is also crazy.

So that's an interesting thing. The second interesting thing is that these proofs can be verified by the virtual machine and RM. So in a smart contract, you can verify a proof that goes outwards, and therefore you can verify work that has been done outside the blood chain. That's also crazy, actually. Like, I think it's the only paradigm where you really have two blocks of chain that communicate with each other.

In fact, you don't need to trust validators who tell you, "Yes, this happened on this chain, here's my signature." You can mathematically verify that this is what happened. Two points that are often discussed when comparing stars to ESNA and SNARK: the first is the cost for verification on the inside. Here, the stars that are Rather, a Snark proof is at a disadvantage. So yes, I would have mentioned Stark and Snark.

They're just two different mathematical protocols to do more or less the same thing, which is to prove that you know something, that you've done something without the other person doing it. Okay, but these two constructions are a bit different. So the first difference is that Stark proofs are more expensive to verify in practice than Snark proofs, giving Snark a slight advantage. The second difference, which is rather to the advantage of Stark proofs, is that generating a Stark proof is 20 times faster than generating a Snark proof. So running the machine inside, two outside, deuterium, which will generate the proof, is 20 times faster on Stark proofs.

The third interesting thing, as I told you, is that the mathematical constructions are based on axioms, fundamental mathematical properties, a little different from each other, specifically on the... Snark is based on different cryptographic assumptions. Snark is based on SHA256 and CDs, while Stark is based on only SHA256. Without going into too much detail, what's cool about this is that, firstly, relying on a single assumption rather than two is better. Secondly, SHA256 has been proven to be quantum resistant.

If tomorrow you have a quantum computer, it wo n't affect SHA256, but consequently, it won't affect Stark's proof. However, CDs are not the case. In fact, perhaps that's the point. It's more about recording failures. In any case, it's not proven that these accounts are resistant, so it's a potential vulnerability of Snark.

And that's it for this slide. The third point, which is also important, is that— and this is another approach we have— what's important is when you build them, but this is more at the level of producing them, they don't really produce proof. It's more about the product itself, but when you're building a product, you have two paths available to ICS and roll-ups today. Basically, either you say, "Well, I have to make a song and IBM, we have to be able to do it and Rome, but in '09, the age..." or you say, "Well, they haven't necessarily done it, maybe the people in this room are under 30, cool, eating and raising their hands, but it's just to get some practice, who knows how to do floor work, is said here, cool, who think that solid ITI and the last language that will learn in their life, well, there you go, you see, it's funny, done when you put it in those terms, obviously you say that, well yeah, maybe if there are more interesting things to do, I'll make the effort to go learn something else."

And we, our approach was to tell ourselves that rather than trying to fit a square peg in a round hole, rather than trying to make a song and VM on a cryptographic system that isn't designed for this, which will be less efficient, just so developers are a little more comfortable in their work, we thought it might be a bit of a shame because we believe that developers are intelligent and motivated, and if we give them the ability to do five, ten, or even a hundred times what's possible on ROMs, it will save them, and they 'll use new tools. Exhaling won't scare us; that's our approach, anyway. That said, yes, it's true, it's an ecosystem that was born a little more difficult to use. That's another challenge. I'm talking about it because I want to.

If this is a topic that interests you, I 'm very happy to talk about it. It's quite funny how we get blockchain developers to do something other than Serengeti. And then, to finish, a little overview. Then I'll present what we've done specifically because I'm the one who knows best how to present things, but who does what in the world of IT services companies. Cayrol, then.

Actually, we can already see that in a majority of projects that use brands rather than Stark, you have Aztecs who, I believe, swiped an initial product that only allows for payments, which is a bit of a sham; it's really focused on confidentiality. You have a Poly Conquered project in development, but for now, it's not really usable yet. You mentioned Gesink, which has made two products: Casting 1, which allows for payment and trading, and ESI, which was Unique and Sync 2, which are still under wraps. It's not really a "has not" because no proof is generated, but you can mention it in the contract; it's deployed within their Stark ecosystem. You have another Polygon team called Mit Den, which has a stage in development that also wants to create Unique and IBM products, which should be available soon, but it will take them some time.

And we, at Stark, have two products: Starke EX, which has been in production since... 18 months, 2 years roughly. Three weeks ago, fun fact: three weeks ago, StarkEx made more transactions in one week than had been doing in the same week, and nobody is holding them accountable. These people are panicking and shouting about the price of gas, it's something like that. Do you imagine that it's going to make the price of gas explode for a week or what?

We're not going to at all. In fact, nobody realized it. Actually, laugh. We're going to see the whole world and both. It's the future, it's not the future, it's the present, and people are using it now.

It's settling down now. Anyway, there's StarkNet, which is the biggest. So, its request is more for making payments and trading. StarkNet is a network that allows for smart programming against arbitrary acts and is currently in alpha, meaning there are bits of tape everywhere. It works, but it's still a very difficult face, but it's cool, and we should be in production.

[Music] I don't really know, I I can't give you a date right now, but I think we'll have made good progress by the end of the year. So, I'll tell you about it briefly, but basically, I can introduce Stark Ex in a nutshell. Stark Ex is the first thing we launched. We started by working on proofs with null disclosure. We weren't going to update 7 Slate.

Since then, things have changed a bit. When we started working on the null divination proof, the first big step was figuring out how to build a programming language on top of it. So, we built Quaero. Once we built Quaero, which allowed us to write provable programs, we asked ourselves how to use it for what it's there for. And so, the first thing we did was Stark Ex, which is a white-label trading engine.

Basically, Stark Ex stands for execution in jeans, and it's used by big companies. Projects like d-wade iex mutable schedules, which lowered the price of gas for the summer hour for their users between 500 and 1,000 times, are actually for exquisite walis using it modestly, and roll up for other clients like his brother, they reduced the price for their users by twenty thousand times twenty thousand, and so what 's quite funny is that it's really a big machine, we also spent 12,500 billion cumulative trading on Stark ex in 3 weeks, it's something that works, it's something that's robust, but well, doing trading is interesting, but we want to tell you it's not very interesting either, we can do lots of other things with the blockchain blocks, we can do identity trout, we can do DNF, we can do lots and lots of things, and so we started working on Stark net, so where are we with this Dark Knight, we've been working on it for about a year, or on the internet, since last July, today during In three weeks we'll be at Fitur around here with RMC, although anything you can do on a site you can do on StartNet, and you can already do quite a lot. Note that you can't do that on a site, it runs, it runs fairly well, a bit slow, and so we want to improve it. So today, we focused on the features of the machine, now we're going to focus on performance. The goal is to be able to handle ten times the number of transactions on StartNet by July.

That's what we want to do by July, and these are the first improvements. We know we can do them. After that, there are a bunch of others coming that will allow us to do really interesting things like fractal scaling. We can talk about that, if you're interested. And another important thing is that the network today is 100% Centralized, operated by Starck Web, meaning it's not decentralized at all; we're the ones running the sequencer and we're the ones with control over it.

It's not very interesting. I don't think I need to convince anyone here that blogs, a decentralized public channel, and Father Michel leaving it open source are much better, and that's what we want to do. That's what we're aiming for. It's not something that can be completely improvised; we want to do it right. So our goal by the end of the year is to have a clear roadmap on the different steps and parameters we'll use to implement the decentralization of Starck 4.

And that's it. I have one last point: we're working with lots of interesting people. If you're sure it's solid, probably yes, at some point you've used contracts to pay 20 to pay 721 written by Open Zeppelin. We work with them; they do the same for Quaero. You can use them; we also work with Never mind, which does a lot of different things, but which notably includes Ward, which is a transport and their robustness towards Quaero.

If you have solid code, you can probably transfer it to Quaero, and we work with different teams. We also offer to have crowds on Stark Net that can be operated by whoever wants. And I've finished my presentation. 20 minutes, cool. Are there any questions?

I was super clear, so here are 1-2. First, thank you for the presentation, it was cool. I didn't know this territory. And my question is, do you use... I use what you presented to us for this case.

It's the terrain via the case helpers, but were you tempted to... what was it like to improve each time? What does it bring you? Creating your own blog, Shane? That's an interesting question.

And I... I've been at Stark for six months, so I'm not going to say everything that's happened in three years. Maybe it's something they considered today, the close that we... Actually, I asked a guy not too long ago if they had NFC. I'll ask, but the country said it was expensive, and Theron, but why weren't you, like, on Polygon or somewhere else?

And he just told me to do it on the ground, but as soon as you have it, well, by Lisette, and that's the case, in fact, I see the fields today, but largely the dominant ecosystems, that's where all the users are, where all the capital is. Is that what we really need to go outside of? Name that makes Theron, it's super practical, it's where the ecosystem is, where there are the most people building things, it's the thing, and it's one of the most decentralized, along with Bitcoin. There are lots of interesting things to do, and Starknet, you can really see it as an extension by two falls and Rome. Actually, it's quite funny, you really have different things that click with different people, there's computing power, there's Others include the fact that you can make really elaborate, even complex, applications, and you can actually have your application on one platform.

There are tenders there, and you can do more with Stark. In fact, doing that means that, roughly speaking, when you build an application on StartNet, technically the liquidity you can use, the liquidity pools, or the apps you can use in your application, make up the lower capacity and that of the Terium. In fact, if you want to put money into StartNet, you can put it into smaller pools, and into Rome (not sure about Polygon), and all that on and off. You can, and I think that's a really cool thing. Yes, hello, I have a question about the cost regarding the publication frequency.

I'm thinking of Lay Reims, who understood this. You're better off waiting as long as possible so that the cost per transaction is lower, but if you wait three weeks, who's to say we'll really have it right? And finally, I don't know how you do it, actually. I see what you mean. Today there are two important parameters in publishing.

Finally, regarding proof, I'm saying today, it's not exactly today. Today, the network is about forgetting, maintenance, and people don't pay for wires, so anyway, it's a cost for us to publish the proof. But in what you're saying, there's an important point: if you publish proof too early, it will cost you too much in terms of the taxes you'll collect on the network. And if you publish it too late, well, screw it. Also, because your proof grows over time, and after a while, you'll reach a point where you can't verify it in a contract, like in Rome, because you'll be out of luck.

You have to have a balance between the two. The closest we have today is that the network is under development, and it's a parameter; it doesn't need to be fixed. You can just have it, and with time, in fact, so concretely, on the internet, I think we publish proof every twelve hours. On the test, nets published proof every two hours, but it's something that can vary, actually. If there are a lot of transactions at once, nothing prevents us from publishing a proof earlier, and if it's slower, it prevents us from publishing it later.

It's part of all the things we have to define to decentralize the network. In fact, these are discussions we have on our forum, so if you want to take part in the discussion, give your opinion, come to Bresse. There are some really interesting topics, and there's no right answer. Goodwill is key, so exchanging ideas is cool. And I had another funny thing to say about this, but I forgot.

Hello, thank you for the presentation. Will the application silos be reduced to ten? Those that are on Stark, for example, will we one day migrate to StartNet. Almost, it will stay the same. That's a good question too.

The simple answer is, it will depend. In fact, maybe yes, maybe no. It will depend on their will. In fact, there will be an aura, maybe. They'll want one, others won't, and in itself, if people prefer to stay in their own little world, why not?

The interesting thing about this is that today, when you run Stark, you're not... because the funny thing is, when you run StarkNet, when you move from block A to block F, you're actually running another node that will thrive, see transactions validated and correctly pass from block A to block F, and it's this proof that's published on its security. StarkNet is written in case of heroism, anyway, but so when you run StarkNet, you can generate a proof that is then validated by the system. That's super cool. There isn't yet the functionality in its query to verify another proof, which would be super interesting because at that point, you see StarkEx, which is connected to the terms, you could connect it to StarkNet, so you could even have your StarkEx identity...

It would be on Starcraft, which would be cheaper, and we know that's possible. The theory, the math, it works; we know it's possible. It's just a matter of engineering time, so it's going to take us a little longer before we can get our hands on that. But once we have that, we can imagine all sorts of things, what we call, in English, fractals, scaling, or fractals. You can imagine having StarkNet, then several StarKate instances run on top of it, so DL3 instances that are themselves verified by StarkNet.

You can have StarkEx on StarkNet. You can have private or semi-private CNETE Stars. You can see Stars that know two consortiums, all of which will talk to the same chain and are able to communicate with each other natively because there are no validators, just math. So, it's a bit of a long answer for a question, it seems harsh. It's a super interesting topic, and actually, it's going to be...

It depends on what the projects want to do, what the users want. Some of you have already done the hero case, oh well, there are some of you who haven't yet but will soon, sorry, go ahead, hello. From the moment a 1-5 year old has control of the validated transactions, what we could imagine is that they can reorganize transactions is the equivalent of the same on an L2, so a value extractor sequel with sandwich attacks and similar things. Oh yeah, absolutely, of course. In fact, the question that arises here is also linked to the decentralization of Staercke Net.

In fact, the other question that arises, which is a corollary to this, is if the sequencer decides not to include the transaction, can it not include it? Yes, technically yes, in fact, the same way as a miner/ VIP insider and ideas to allow the transaction or sandwiches and/or to do all these things. The risk that specifically on A rollup, in fact, means that you can have your chain moving forward, but generating the proof takes some time. So, we need to understand that today, if it's approaching, it's about having a consensus on Layer 2 that will allow you to say, "OK, the transaction will be included in a proof." Then the proof degenerates and is sent to the fields.

The problem we have with this is that if you say "good enough" in a block and then the proof manager wants to change the blocks, they can. So, we're separating the roles of sequencers and provers so that the sequencers decide which transactions go in the blocks. The proverbial one is forced to take the list of transactions that has been decided by someone else. But here's the question of security on relays; it clearly arises, especially since, as I explained, relays allow you to do a bit of smart contract execution, which is what we do today with security. That's where you Delegate it to specialized actors and then control their work.

You don't control it by saying they're acting in good faith; you control it with math. The problem is that if you have the timeframe that specialized actors have, well, they have huge machines and they'll potentially try to maximize their profitability. So I don't know if the same thing is really avoidable on public channels. And I think the big thing that's going to happen is... we're all thinking about it.

They're in sandwich attack mode on Uniswaps and decentralized finance stuff, but in gaming, that's where it's going to cause the most problems. Probably the confidentiality on the young blocks will come through gaming because kids are all rage-quitters, and if you frontrunner transactions, they're going to be too angry. So you'll be forced to implement solutions to limit it. Thank you very much, thank you Henri. I suggest...

yeah, you can applaud him. [Applause] [Music]