Les Amis d’Ethereum France #18 — Les deuxièmes couches ft. Zksync, Starkware, Cometh

In short, Ethereum France is a non-profit organization (under the 1901 French law). We've existed since 2015 and been active since 2016. We do three main things: events like this one, an annual conference ( etc.), and we publish content on our blog. We translate articles and, more generally, we're a small community of active members.

We have a Discord server where you can participate, a Meetup group where you can find all our Meetups (including this one), and our Twitter account (we manage the Ethereum France Twitter account). We also manage the LECC and etc. Week, which is the week of events surrounding our big conference that I mentioned. And we have our YouTube channel, the association in France, where you can find this current Meetup, all previous Meetups, and all the content from our CCI conferences. So there's a lot of really interesting content that's renewed every year.

You can join the association, even though we're currently experiencing a small technical problem. Generally, you can become a member, which allows you to contribute. The association encourages you to write articles on our blog and organize Meetups in your city. If you're not here, or even in Paris, you can help us organize Meetups and more generally participate in the association. And without further ado, I'll give you a quick overview of this year's program.

We'll have a first talk by Lucas from StackWare, followed by Esteban from zkyc, and then a presentation of an Optimism implementation by Comette with Le Paludier. This will be followed by a small get-together with drinks and pizzas. So, I'll hand it over to Lucas from StarSquare. Thank you very much. [Music] Hello everyone.

I'm Lucas from StarSquare. I'm on the exploration team, and basically, our goal is to create open-source projects related to everything from StackWare and StarKnet to StarKnet. This is validrollup, so I'm going to explain how it works in detail. This will also help you with the presentation later. Basically, we've come to the conclusion that Ethereum only appeared in 2015, and Ethereum is actually much slower than payment solutions that came out much earlier, like IP addresses or credit cards.

So why is this happening? Today we have two solutions: banks or Ethereum. With banks, everyone trusts the bank to maintain their account balance, process their transactions, and so on. With Ethereum, it's the opposite: no one trusts the bank, and I double- check everything. Nothing is anonymous, and everything can be verified by anyone.

So one is very fast because it has a large machine that executes everything, while the other is very slow because there are many small machines that re-execute everything. So the question is, how do we find a middle ground between the two? And to be able to have a fast but secure network, so either we can increase the block size limit, which has been done in many blockchains, but actually it's not great because, well, all the people with very small devices 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-function (ROP) systems, like Arbitrum and 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'll 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 fact, like a transaction, we have a proof, which is a large server that will prove it, and we have the verifier that will verify the proof. It's a bit similar to proof of work in the sense that there are machines that will do the work.

for a certain time and verify what the proof is. It doesn't take long because it's just recalculating an H, so it's a bit the same concept. So we would have a new architecture where we have a blockchain that receives all the transactions, a sequencer that receives, orders, and executes all the transactions. We have the pro that will re-execute all these transactions, prove them, and we will have a verifier that will verify this proof. And applied to Ethereum, it gives this: the computer will crash.

So we have the proof in the middle. I can put the pro in the middle, which will post the proof on Ethereum, and therefore we gain security because all the nodes of Ethereum will re-execute the verifier's code, the verifier's code. So basically, all the checks are OK. So we post the proof on Ethereum, but we also post the state updates, that is, all the state variables of the smart contracts. If, for example, in a contract, we have stored at location 3, we have stored, well, we post on Ethereum the contract update x 3 2 and So, in fact, we can reconstruct the entire state of the chain using only Ethereum.

We also have the proofs, so we can verify them. Therefore, we have a network that is completely trustworthy and secured by Ethereum. Okay, so what does that give us? It gives us really cheap computing power, and it allows us to do quite a lot of things, 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, it's in the style of Autonomous World. And we have DAP, which already exists in AB Brick. It was an NFT concept where you could basically buy bricks and then assemble them, creating something a bit like Minecraft, creating larger NFTs. And that requires a huge amount of computing power to calculate the shapes and so on, and that's possible on Starknet because it's cheap. On Ethereum, it would be really expensive.

We can also have Liia Unchain; we had a trading bot. Unchain, made by Modulus Lab, uh, and so it traded by sending messages on Layer 1, so, uh, well, it was trained, and uh, we could ping it, and then it made trades uh, directly on Ethereum, uh, yes, Gaming Arts and so on. We also have uh, native account abstraction, so account abstraction. This is the fact that we're not like on Ethereum, we don't have a private key and a public key. Basically, on Starknet, 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, in fact, we can, if we want, not just verify a specific curve. For example, we could have several signature schemes.

So, for example, you all have a phone, and it Everyone has a secure enclave, and basically, it's a small, secure component in your phone that has a specific elliptic curve. So, in your smart contract, you can code a function that verifies a signature of this elliptic curve. And, well, you can then verify signatures on your phone. We have a Wallet that does this, kudos! Basically, you have a key, which is HWallet, that allows you to make transactions.

You can say, "Well, I authorize this type of transaction," and so on, or whatever. And this key is stored on your computer. You have a master key, which is your Face ID, that allows you to send a transaction to change the HWallet key, and so on. So, that's super convenient. You can also have keys.

Basically, you give a signature to a DAP (Data Access Point), and it can reuse it to send transactions to specific contracts for specific functions. So, that's cool for games. You can also group transactions; for example, if you want to do an approval, a transfer, a swap, and... Well, you do that in the same transaction, you do n't have to sign a transaction three times. So, actually, it's cool for pretty much all uses.

We also have a trustless bridge. Optimistic rollups are based on game theory. Basically, you stake time, and if you do something wrong in Layer 2, you can get slashed. It's on Starknet, Zik5, and others. In fact, everything that happens in Layer 2 is proven.

So, for example, if I say I want to bridge some ether on Starknet, I send some ether to a contract. The Starknet sequencer looks at the events of that contract, sees "received et des terres" (received et des terres), and it will consume the message in Layer 2. So, it will execute a transaction that says "Mint et des terres" (Mint et des terres) at that price, and so it will be proven. Then we send the proof back to Layer 1, and it's verified. Ethereum is quein, Ethereum isn't, but we finally verified that the message was consumed and that we didn't Mint 300 Ethereum 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 Avav too. You can also do Defy pooling with it, meaning, for example, if we all have €1 and we want to stake it on Lido, well, if we do it on Ethereum, €1 goes into gas. If we do it on L2, we all pool our money, we all put in €1, we end up with €100,000, we bridge it on L1 and stake it on Lido and we pay much less. Storage proofs are also important; basically, this stems from computation, which is very cheap.

Storage proofs are proving the... The way to finally prove that we have a leaf in a Merkel tree, basically, if we have the State Rot of Ethereum, it's... I don't know if everyone is familiar with it, but basically, Ethereum is a Merkel tree, it's a tree, and we re-dig everything, and that gives us an executable, and we can prove that we have, well, that there's a leaf that has a place in this tree by giving the whole path and so on, and it will be rebuilt. And that's extremely expensive because there are a lot of H's, 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, "Well, I want to Minter 30," and to a guy who has 30 and is in L1, and so with this S proof, well, he can put it, send it to the contract on Starknet, it will be verifiable, and we Minter 30 will be able to do this, and that's if we don'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 that can allow for multi-chain transactions. Hodotus does quite a bit of cross- chain 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, appchain, and so on. Basically, everyone can deploy their appchain. For example, you can put a Starx on a Starknet; you just need a verified contract.

The same architecture as in L1, but in L2. And that allows you to have networks that are optimized for certain use cases. So, as I was saying, STARC is optimized for trading. It allows you to have, for example, a trading platform. We could put it in layer 3 that is hosted on Starknet, and that would further reduce its footprint compared to...

to etherum 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 from Solidity to their language, so they also have their DSL, which is the equivalent of KO, but nobody actually uses it. They only use the Solidity to Zin compiler.

But there's an overhead because you have to compile Solidity to Zin, whereas with KO there's no overhead; it's natively optimized for that. But it's a bit slow because we have our own code, our own language, so it's slow because our VM has overhead. Anyway, so what we The goal is to make it as fast as the others, the others being CC++, Rust, and so on. In fact, all these languages are fast because they use tooling that has existed for a very long time, which we can't do because we have our own language. Basically, they all use an intermediate representation, which is LVM.

So, an intermediate representation is LLVM. And there's an optimizer, coverage, compilation to WebAssembly, to RIS5, etc. Anyway, there's a lot of tooling. So, we make a compiler to compile to LVM and be able to compile to x86, which would be executed natively by the processors and would save a lot of DPS. There's a short explanation of how it works.

I'm not sure if many people are interested. Raise your hand. Okay, one person is enough for me. So, basically, this is a KO program, which is quite simple: 1 + 2. This is its representation in Sira.

Sira is our intermediate representation. It's basically a set of... These are bits of assembly code that will always be provable because before, you could actually do ACERT 1 e= 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 e= 2, well, it was a rip-off, but you could n't include it in a block because you would n't have been able to prove it. So the sequencer did DOS, and so we created our intermediate representation.

And so here we have the types that are used in the program. These are the Lip Funk types. So these are the casum code snippets, or rather assembly code snippets, that are declared here. This is the body of the program, and below is the function name with the line where it starts. So this is main, and it starts on line Z0, so instruction Z0, and then we follow what happens.

And so this is the snippet of code in LLVM. So here we find a bit of everything; 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 this—basically, just the result. So, something that would have taken us a lot of time in CO (because Queen makes each lipfunk, which is several Cairo instructions) is transformed into a single instruction, an LLVM instruction, which is then compiled natively, so x86, to be executed directly by the CPU. It's quite fast because otherwise it's rather long.

But I invite you to watch this presentation by Aki from Lambda Class; they work on native Ciro. Basically, I talked to you about Cairo in LLVM, but they actually made Sierra in LLVM. They made Sira, which is another intermediate, slightly more modern representation. And he gave a pretty interesting presentation at Starknet CC this summer, if you weren't there. And that's it, that's the end.

This is the link to the Starknet Book, so it's the equivalent of the Rostbook, but for Starknet, so if you want to start somewhere, this is a good [Applause] place. Good evening everyone. First of all, thank you very much to France and Nathan for organizing this Meetup. It's great to be here with you tonight. My name is Esteban, and I 'm a community manager at Zing.

I've been with Malor Labs for two years now. Tonight, I'd like to talk to you about three topics: firstly, Zik Credo; secondly, Zik Syn; and thirdly, Zik Stack. Recently, there was an article on Vitalque's blog calling on the community to make Ethereum Cyherpk again. It's Cyherpk, it's vague, but at the same time, there are some values ​​in the Cyherpk movement that people aren't ready to compromise on. One of them, for example, is resistance to censorship or having systems where trust isn't necessary.

We can verify the integrity of transactions, the integrity of the blockchain, security, and privacy protection. These are values ​​that are central to the Cyherpunk movement, and the team at Mateur already published a document in September called the Ziking Credo. It's now available on GitHub in French: github/ziking/cedo. You can find it in French in which we write down our commitment to Cyherpunk values and Zero Proof EU technology. I wanted to share this, and the values ​​of Ziking and Credo are also the values ​​that guide our development of the protocol.

But now, let's get to the heart of the matter. I'm going to talk to you about rollups. You may know that there's a large family of Layer 2 rollups. The two main families are the Optimistic Rollups and the Ike Rollups. As Nathan and Lucas mentioned earlier, the Optimistic Rollups are...

A bit of game theory: they are secured by social consensus, while ik rollups are secured by mathematics. Within the zik rollup family, we also have a vital distinction: types 0, 1, 2, 3, and 4, which are actually different, let's say different compatibilities with VMs or equivalences with VMs. But we could introduce another distinction: what is actually proven by the Zero Proof system? If we have solutions like the ZKVM polygon or ScrollVM, in which each transaction, or each transaction, has its validity proven by a Zero Proof. In systems like StarAre or Z, what we prove is not the validity of a transaction, but the validity of the transition of the UM (Unique Machine) of the virtual machine.

In fact, what we prove is that the Ethereum virtual machine has time T and transitions at time t + 1. We prove that this transaction transition is valid, there are many advantages in fact to using this type of architecture. I'm going to spend a few minutes presenting this architecture, but one of them is chip fees, gas fees which are rather low, privacy, transaction confidentiality, and in fact Starsquare, Zikera, and Zik St use this type of architecture where we prove that the The transition of the Ethereum virtual machine is correct using a combination of Stark and Snark. There are three advantages that I will mention here to demonstrate the transition of the Ethereum virtual machine. The first is that when you frequently need to update storage slots, it becomes very cheap on Z-casing or Stark because you only need one storage slot at a time, and in between, you can update it as many times as you want.

This makes it very cheap. For example, we see oracles that are extremely fast. Today, I believe we update an oracle approximately every 20 minutes. We can imagine oracles that are updated every second because it is very cheap. The second reason is that, since we combine them, we don't need transaction integrity; we do n't need the entirety of the transaction.

For the transaction, we only need a batch, and then to prove that the transition is correct. In theory, we could make the data of these transactions accessible only to the people who issue a transaction, and thus natively have a certain form of confidentiality or privacy. In fact, on the second layer, and I think this is the most important and interesting, is what we call horizontal scaling. This means we can have vertical scaling in the case of monolithic blockchains like Solana, or we can have what we call horizontal scaling, meaning having an infinite number of applications running but not constrained by a bottleneck, for example, like a Squeeze or your P. We saw this recently, for example, I think between October and January, there were many VM chains that were spammed by registrations.

I don't know if you Did you see that? We saw the gas Fs that have, that have swiped on Optimism Arbitrom on Polygone ZikVM, but not on Zik. And in fact, that's one of the reasons why it happened. It's precisely because of state difference, and because we batch the transactions, we batch them. And then, unlike Layer One, the more transactions happen on Layer [Music], the fewer, in fact, the cheaper the gas Fs per transaction will be.

I think there's a consensus within the community that most of the gas Fs costs in the future, well, in the future, in the short and medium term, will be mainly due to data availability costs. We have solutions like Celestia, which is starting to emerge, which, for these cheap gas Fs, we can do it and then depend on, let's say, trust assumptions that are a bit different from Layer One, or we can use architectures that put all these transactions together and then prove the validity of these transactions, like... As with what we do on ZK, I invite you to read two articles that I think are super interesting. One is written by Paulinaya (I don't know if you know the researcher), and the second is written by Onekx. Both of them argue that state transition might be a very interesting design for making Ethereum scalable and cheap.

The practical implementation—that was the theory. The first practical implementation was Zikera, which is a layer two layer that uses zero-knowledge proofs. We upgraded our proof in December with a solution we call Boum Boujum, and since December, Zikera has been consistently used. It's the layer two with the lowest fees on the market, by a large margin compared to other ZVMs. They don't even have large polygons or scrolling because we use this architecture.

Another advantage for you: if you develop applications on ZVMs, you can deploy them on ZK Syn. There are a lot of users, I think we have one of the highest user activity levels since we went on Mnet in April of last year. And finally—and here, in quotes, we are secure. You can never be too secure, but we've done a lot of audits with Code for Arena. We had a bounty, I think, of 1 million, Alborn Open Zeplin, several Trail of Bits audits to secure the various elements of ZK Sync.

ZK King is a layer-two; it was created by Matterlabs. But you also have the option to create your own layer- two. You may have heard of Lopy Stack, which allows you to create superchains. There's a similar solution, but instead of using FR Proofs and Optimistic Rollups, you can use Zik Rolls, and we call it the Zik Stack. The Zik Stack is also a stack that was created and produced by Matterlabs.

I'll show you— I invite you to visit the website zkestac.io. Essentially, it allows you to... to deploy your own layer 2 or layer 3 which therefore settles on Zik will be, uh, in a completely customized way. You can have, uh, a rollup with a centralized sequencer.

You can pay your gas fees in any ERC20. Uh, you can have a blockchain that is completely private, or you can, well, whatever your needs, you can use the Zik stack, the technology behind Zikera, to deploy your blockchains in layer or layer 3 which is on Z. As mentioned, fractal scaling is very similar to what was presented before. It's the concept of fractal scaling. From the moment blockchains share the same architecture, the same proof of concept, the same verification, we can imagine ecosystems in which we can bridge between blockchains in a trustless way.

And there you have it, we can imagine that. We don't need to fragment liquidity between the different blockchains either if you share the same architecture, the same proof of concept, the same circuits, and so on. Ziking opens up scaling possibilities that are virtually limitless, meaning you can scale very horizontally with any type of application, or vertically by adding other applications within it, for example, on a layer. I don't know if you have any questions about the technology; we can talk about that right after. I just wanted to say a few words about the Ziking community.

We have a large community hub in Asia, and also in Eastern Europe. Ziking Japan, Ziking China, Ziking Ukraine, and Ziking Indonesia are large communities. Maybe one day we'll have Ziking France. We're always looking for ambassadors or people who are ready to represent Ziking worldwide. So, if you're interested, feel free to send me a DM either on Discord or Twitter, and we can discuss it.

Thank you. Hello everyone. My name is Augustin, and I've been working at Comè for a year and a half. As a data analyst by training, I now work on rollups, as you can see. You should know that at Comet we have an on-chain video game, and running an on-chain game costs a lot of money.

Our game currently runs on Polygone, and at one point there was talk of migrating it to a rollup. My boss came to me and asked how much it would cost to run the game on a rollup, and I naively thought it would be an easy question to answer. It turns out it's much more complicated than that. Rollups like Optimism and Arbitrum have very different ways of calculating transaction fees, and I'll explain a bit about the history of the Comet game and how we came to the decision to migrate to a rollup. I'll then give you a general overview of how a rollup like Optimism and Arbitrum works, and I'll explain in more detail how transaction fees are calculated on this type of rollup.

I will explain a DAC implementation we developed using Optimism, and therefore the necessary modification to the transaction fee calculation to account for this implementation. Finally, I want to talk about the solution we chose for our next game. So, we started in 2021 with a fully on-chain game where all player actions were performed on- chain on Polygon. This was a time when the cost of using Polygon was particularly low; the MATIC was very, very low, and the number of transactions on Polygon was extremely low. For players, it was quite profitable to play, especially since it was a play-to-earn era in early 2021, so players needed to be able to earn money.

However, a few months later, the network crashed, and it became more difficult for players to earn money. There was already a growing player base, so the reward per player was becoming less and less important, and above all, the MATIC and gas prices skyrocketed, making the cost to play the game extremely high. Players were getting more money than they could afford. In 2022, we released a new game, still on Polygone, called Comet Battle, which is actually a trading card game with less Unchain interaction, but it still has assets. So you have avatars that are kind of like your character, you have cards that are NFTs, and you also have crafting resources, which are ERC20 tokens used to craft cards.

At the end of each match, the winner of a game against another player received rewards, and these rewards were sponsored by Comet. Unfortunately, the cost of these rewards was always too high. For example, we had a ship rental system where the renter could take a portion of the rewards, and the owner took another portion. This meant that the reward transactions were quite large, with many ERC20 transfers, and at a certain point, it was costing us almost 10 cents per game won. For a game with almost 500,000 matches, it started to become extremely expensive for us to maintain.

of the game, and finally, we will soon release a redesigned version of Comet Battle called Cosmic Battle, and our goal is to deploy it on a rollup. So, rollups like Optimist and Arbitrom work this way: when you pay for a transaction on Ethereum, you have two main costs: the transaction execution cost and the data availability cost. If I were to give an example, for instance, if you want to make a transaction that is the addition of 1 and 2 on Ethereum, the execution cost would be the calculation 1 + 2, and the data availability cost would be the parameters of this addition, which would be 1 and 2. Most of the time, the large part of the cost of a transaction on Ethereum corresponds to the execution, but you can still have transactions where data availability is very important. Typically, when you put an NFT up for sale, you have in the transaction parameters all the parameters of this listing, and this is the most important cost in this transaction.

That's why today on OpenC, when you sell to NFTs, most of the time it's an off-chain order. You just have to sign a transaction, and that transaction is no longer executed by the network. What Optimis and Arbitrum do is shift this execution cost to the rollup but keep the data availability on Ethereum. This saves execution costs because the execution is done on the rollup with an extremely low gas price. So, when you make a transaction on the rollup, the blocks are validated little by little, and after a certain time, all these transactions are concatenated, compressed, and sent to L1 with what's called a batch transaction.

This batch transaction has a maximum data limit of 9 to 9.5 billion to fit in a block on L1. So, what is the cost of a transaction on Optimis? You have two main components: the execution fee, which is calculated on the rollup. With the gas price, you have an extremely low gas price.

It follows the same principle as Therum with IP 1559, and the data is collected directly by Optimism. You then have a second component, which is the Data F, which is the cost— the fee—you have to pay to publish your transaction data on the L1 network. This L1 Data F is calculated by taking the size of the transaction data and the gas price on the L1 network. This F is directly deducted from your wallet by the Optimism network. If you look at the OP Explorer and examine the details of the gas F, you have the total transaction F.

Here, after the gas price, you have the gas limit, the gas F—a fairly standard IP 1559 structure. But then you have new fields: the L1 F paid, which is the total F you paid for publishing your data on the L1 network, and the L1 gas price. L1 is updated with each rollop block, the US gas is used by the transaction, so in fact, we calculate the gas it would consume to publish the data on L1, and there's the L1 fiscal, which is actually a variable determined by optimism that allows us to lower the cost of the transaction. It doesn't specify exactly how this variable is calculated, but logically, it includes part of the compression they manage to achieve and a small margin. To calculate this L1 data, we take the transaction data, count all the bytes that are zero, multiply them by 4, and all the bytes that are 16 or higher that are not zero, multiply by 16.

It's exactly the same method on Ethereum to calculate the cost of the data you're going to post. It's the data gas, and then we add a fixed overhead, which is ENIT at 188, of gas, which has another cost. A fixed fee for each transaction that must be posted to L1, plus the dynamic overhead of 0.684 determined by Optimis, and finally, once that's done, you just multiply that by the base feed of iRum, and you have the L1 data fee you'll pay for your transaction on Open Mainnet. This allows for a significant reduction in transaction costs, but unfortunately, for gaming, it's not enough because the cost of data is still quite high.

At Comet, in our game transactions, we often have a lot of data corresponding to the parameters of the match won, who won, which token ID of the winning ship, so we still have a fairly significant data cost. iRum is a little different; it still follows a similar principle to OpenNet. There's still the execution fee, which is exactly the same, except for the L1 data fee. There are a few differences, notably two major differences: the L1 gas price, which isn't a... which is not the current L1 gas price but an estimate that was made with a calculation I will show later, and uh, the L1 data isn't directly deducted from your wallet, but it's converted into L2 gas and added to the transaction total.

So if we look at the Explorer, we can see that the typical L1 gas is a transfer transaction, normally it's 2000 gas that the person paid, almost 3,320,000 gas. In fact, this additional gas corresponds to the converted gas. To explain the system they've implemented, every time someone makes a Surbitr transaction, the data sent in a contract is called Pr, and this Pr has a variable inside called the balance. This balance increments each time a block is validated on L2 with all the data. Once L2 wants to send a B transaction to L1 and this B transaction is validated on L1, it There's a transaction sent to the L2 called a batch posting report, which includes several parameters and information, such as the gas price.

Using the gas price of the batch transaction, this information is sent to the L1 pricer/fund pool and deducted from the balance. So typically, they collect the L1 data pool, accumulate it in this contract, then collect what was paid on the L1 and subtract that from the balance. The sign of this balance will depend on the following: if the balance is negative, meaning there's a deficit, the L1 low F estimate used to calculate the data pool will be increased; if the balance is positive, there's a surplus— they paid less than they collected—so they will lower the L1 low F estimate to try to always get close to zero. So, unfortunately, for arbitrage, it's always the same: the F transactions are always low, but not low enough for gaming. So, there was a solution, which would be...

Your own solution, therefore, is a DAC implementation with a focus on optimism. A DAC is essentially taking the Data Availability layer, which was previously on Ethereum, and putting it off-chain. To put it off-chain, we use exactly the same method as with Optimis: the data of your transaction is compressed and, instead of being sent directly to the L1 layer, is sent to a DAC. A Data Availability Commit is sent to this DAC, where each member attests to and signs this data and sends the signature back to the sequencer. What you need to understand here is that when a DAC member attests to and signs this data, they promise to make this data available to anyone who requests it.

Then the sequencer takes this signature, creates a certificate, and posts it to the L1 layer. The certificate has a fixed size, so the cost of the data posted to L1 is always fixed. You can use this certificate to retrieve the transaction data and use it with the API of one of the DAC members, since the The cost of the data posted to the L1 is fixed. We can modify the formula that calculates the FI transactions to further reduce these costs. The objective was to modify the Optimism stack as little as possible, so we decided to modify only one parameter in the calculation of the L1 data FI costs: the Dynamic Overhead.

To modify this dynamic overhead... Overhead, we have several pieces of information. We know that a Bâ transaction only costs 24,000 in gas, and that will always be the same. We know that the maximum data we can send to the DAC is 9.5 MB.

So why do we have this maximum? That is, if the DAC fails, the rollup automatically switches to normal mode and posts all the data to L1. So that's why we have to keep this 9.5 MB limit. It's to stay within the scope of the basic rollup.

We have to modify it; we have to do a small calculation that modifies, or rather, makes a rough estimate of the transaction size after compression. This gives us an extremely low preliminary dynamic overhead, almost 900, less significant than in Optimism. And I say preliminary because there's an important aspect that Optimism doesn't have, but that we can have for small blockchains: when there's a low transaction volume, a certain amount of time can pass between the moment the user pays for their transaction on the rollup and the... The moment we pay for the publication of data on the L1 blockchain can be dangerous because we might not have collected enough fill to sponsor these transactions. Therefore, we decided to set a time limit.

Even if we haven't reached 9.5 million blocks, the trigger to initiate this batch transaction is set at 600 blocks, which is 2 hours. To limit this risk, and considering the maximum variation that can occur over 2 hours, which is absolutely enormous, we decided to conduct a small statistical study of the base-fi blocks. We analyzed 1.25 million blocks between December 2022 and May 2023 and examined the variations between blocks n and n + 6.

We found that in 9% of cases, this variation was below a 269% increase. And, as a side note, the largest variation we observed was a 25,000% increase. 2 hours is a bit expensive, so now that we know that in 99% of cases the increase will be below 269%, we can just modify—if I manage to get to the next slide—we can just modify the calculation we saw previously, multiplying it by what I'll call the uncertainty factor, which is 3.69. This allows us to have an extremely low dynamic overhead.

To compare, an approve transaction on Open, which costs, with a gas price I think, 30 quetzales, and on ETH at $2500, the cost of a transaction on Open would be 14 cents, and on Comet, with our implementation, it would be 2 cents, or 600 times cheaper. This DEAC implementation received a GR from Optimism, so GG to Ladar, who is right here and is the brains behind this implementation. You can use the QR code to go to this page, and all the information is there. The code is open source. And the documentation using this QR code, uh, and GG was also ROM France, which received a Grun for during this round, so in this case, the F transactions are really, really cheap, but on the other hand, it's still a work in progress, we need to have it audited, uh, it's research, so we're still working on it, and then in the meantime, we were approached by Arbitrom, who were about to release their Orbit chain, which is L3, and we thought we'd try the adventure with them.

So today, our next game will be released on an L3 Enitrus Orbit. Enitrus is the implementation, it's DAC, we were very inspired by them, and the L2 would be Arbitrom One. But having your own chain brings many challenges, like having an indexer, having solutions for a DROM, which is extremely complicated to have on small chains like this, having a PC audience, and so on. And these are challenges that I think we will be able to solve. In a little while, thank you very much [Applause]