Les frais de transactions sur les Optimistic Rollup - Augustin de La Ferrière

Hello everyone, uh, my name is Augustin. I've been working at Comet for a year and a half, initially as a data analyst, but today I 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 video game costs a lot of money. Our game currently runs on Polygone, and there was talk at one point of migrating it to a rollup. My CTO came to see me and asked how much it would cost to run the game on a rollup, and I naively thought that question would be easy to answer, but in fact, it's much more complicated.

It turns out that rollups like Optimism and Arbitrum have very different ways of calculating transaction fees, and I'm going to 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 explain in broad strokes how a rollup like Optimism and Arbitrum works, and I'll explain with More details later on how transaction fees are calculated on this type of rollop. Then I'll explain a DAC implementation we did on Optimism, and therefore, the modification of the transaction fee calculation to take this implementation into account. Finally, I'll talk about the solution we chose for our next game. So, Comè, it starts in 2021 with a completely on-chain game where all player actions are done on Polygon.

At a time when the cost of using Polygon was particularly low, especially the MATIC, which was very, very low, and the number of transactions on Polygon was extremely low. For players, it was quite profitable to play, especially CIT. At the beginning of 2021, it was play-to- earn, so players needed to be able to earn money. However, a few months later, the network exploded, and it became more difficult for players to earn money. There was already a growing player pool, so the reward per player was becoming less and less important, and especially the MATIC cost and the gas price.

It exploded, and as a result, the cost to play the game was extremely high, and players weren't earning any money. 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 ships that are kind of like your character, you have cards that are NFTs, and you also have crafting resources, which are ERC-20s used to craft cards. At the end of each match, the winner of a game against another player received a transaction, a reward, and this transaction was sponsored by Comet. Unfortunately, the cost of this transaction was still 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 significant, with many ERC- 20 transfers, and at a certain point, it was costing us almost 10 cents per game won. Where there have been almost 500,000 games, it started to become extremely expensive for us to maintain this kind of game. Finally, we will soon release a redesigned version of Comet Battle called Cosmic Battle, and our goal is to deploy it on a rollup. Rollups, like Optimist and Arbitrum, 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 of 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 use an NFT. When selling, you have all the parameters for this slotting process in the transaction settings, and this is the most significant cost in this transaction. That's why today on OpenC, when you sell to NFTs, most of the time it's off-chain orders. You just have to sign a transaction, and this 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 on execution costs because the execution is done on the rollup with an extremely low G Price. So, when you make a transaction on a rollup, the blocks are validated little by little, and after a certain time, all these transactions that have passed are concatenated, compressed, and sent to L1 with a transaction called a batch transaction. This batch transaction has a maximum limit of 9 million to 9.5 million.

Data is needed so that it can fit into a block on the L1. So, what is the cost of a transaction on Optimism? You have two main components: the execution fee (FE), which is calculated on the roll with the gas price of the network. Therefore, you have an extremely low gas price. It follows the same principle with IP 1559, and the fees are collected by Optimism.

The second component is the data fee, which is the cost—the fee you have to pay for publishing your transaction data on the L1. This L1 data fee has parameters; it is calculated by taking the size of the transaction data and the gas price on the L1. This fee is directly deducted from your wallet by the Optimism network. If you look at an Opet explorer and examine the gas fees, you have the total transaction fee. Here, you have the gas price, the gas limit fee, and the gas fee—a fairly standard IP 15559.

But then you have new... The fields that are the LM F paid, so that's the total you paid for publishing your data on L1, the L1 gas price, so the L1 gas price is updated with each ROP block, the US gas per 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 for you. It doesn't specify exactly how this variable is calculated, but we can logically assume it includes part of the compression that we manage to achieve and a small margin that is used to calculate this L1 data. So we take the transaction data, we count all the bits that are 0, we multiply them by 4, and all the bits that are not 0 and by 16. It's exactly the same method on Ethereum to calculate the cost of the data you're going to post on it.

That's the gas data, then we add... The fixed overhead of 188 gas, which again has a fixed cost for each transaction that must be posted to L1, plus the infamous dynamic overhead of 0.684 determined by Optimis, and finally, once that's done, you just have to multiply that by the base feed (etherum), and you have the ELIN data feed that you will pay for your transaction on Open Mainnet. So, this allows for a reduction in transaction costs, which are quite significant, 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, and the ship that won the match.

We still have a fairly significant data cost. BitROM is a little different; it still follows a similar principle to OpenNET. There's still the FEI execution, which is exactly the same, except that L1 data feed has some differences, notably two major differences: The L1 gas price is not the actual L1 gas price, but an estimate calculated using a method I'll explain later. The L1 data isn't directly deducted from your wallet; it's converted into L2 gas and added to the transaction total. So, if we look at the Explorer, we can see the gas limit.

Typically, this is a transfer transaction, and normally it's 21,000 gas. Since the person paid almost 300,000, this additional gas was converted to L2 gas. To explain the system they've implemented, every time someone makes a transaction on Arbitrom, the data is sent to Unat, which is called the L1 pricer F pool. This L1 pricer F pool has a variable inside called the sold value, and this sold value increments each time a block is validated on the L2 with all the... L1 DataFi: Once L2 wants to send a batch transaction to L1 and this batch transaction is validated on L1, a transaction called a batch posting report is sent to L2.

This report includes several parameters and information, such as the gas used and the gas price of the batch transaction. This information is sent to the L pricer/pricer/fund pool and deducted from the balance. So, typically, they have recovered the L1 DataFi less accumulated in this contract. They then recover what was paid on L1 and subtract that from the balance. The sign of this balance will depend on the following: if the balance is negative, meaning there is a deficit, the L1 low estimate used to calculate L1 DataFi will be increased.

If the balance is positive, meaning there is a surplus, they paid less than they collected. Therefore, they will lower the L1 low estimate to try to always achieve a balance close to zero. So, unfortunately, for arbitrage, it's always Similarly, transaction fees are always low, but not low enough for gaming, so a solution would be a do-it- yourself solution: a DAC implementation. On the Optimis server, a DAC is essentially taking the Data Availability layer, which was previously on Ethereum, and putting it off-chain. What we do is use it exactly like Optimis: your transaction data is compressed, and instead of being sent directly to the L1 layer, it 's sent to a DAC, a Data Availability Committee.

Each member of this committee attests and signs the data and sends the signature back to the sequencer. The key point here is that when a DAC member attests to this data, they promise to make it available to anyone who requests it. Then the sequencer takes this signature, creates a certificate, and posts it to the L1 layer. Therefore, the certificate has a fixed cost, so the cost of the data posted to L1 is always fixed. You can then use this certificate to retrieve and use it with the API.

From one of the DAC members, to be able to retrieve transaction data, since the cost of the data posted to L1 is fixed, we can modify the formula that calculates the FI transactions to lower these costs even further. The objective was to modify the optimization stack as little as possible, and so I decided to modify only one parameter in the calculation of the L1 data FI, which is the Dynamic Overhead. To modify this dynamic overhead, we have several pieces of information: we know that a Bâ transaction only costs 24,000 in gas and that this will always be the same; we know that the maximum data we can send to the DAC is 9.5 m. So why do we have this maximum?

That is to say, if the DAC fails, the rollup automatically switches to normal mode and posts all the data to L1. Therefore, we must keep this 9.5 m limit; it's to stay within the scope of the basic rollup. We need to modify it; we need to do a small calculation. Basically, this modifies what makes a rough estimate of the transaction size after compression, giving us an extremely low preliminary dynamic, almost 900 MB, less than in the optimistic scenario.

I say preliminary because there's an important aspect that optimistic doesn't have, but which we can have for small blockchains: when there's a low transaction volume, there can be a certain amount of time between when the user pays for their transaction on the rollup and when we pay for the data publication on the L1. This can be dangerous because we might not have collected enough FIB to sponsor these transactions. So, we decided to set a time limit. Even if we don't reach 9.5 million, the trigger to initiate this batch transaction is set at 600 blocks, which is 2 hours, to limit this risk.

Therefore, the maximum variation that can occur over 2 hours is absolutely enormous. decided to do a small statistical study of block balances (BLs) on blocks, so we analyzed 1.25 million blocks between December 2022 and May 2023. We looked at the variations between blocks n and N+6 blocks, and the variation in block balance ( B). We saw that in 99% of cases, this variation was less than a 269% increase.

As a side note, the biggest variation we saw was a 25,000% increase in 2 hours, which is quite expensive. So now that we know that in 99% of cases the increase will be below 269%, we can simply modify—if I manage to get to the next slide—the calculation we saw previously. We can multiply 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 OpenMethod costs, with a gas price I believe, 30 gu, and an e to $2500, the cost of a transaction on op would be 14 cents, but on Comè on naturement it would be 2 cents, or 600 times cheaper. This DAC implementation received a GR from Optimism, so GG to Lacdar, who is right here and is the brains behind this implementation. You can use the QR code to go to this page, and there's all the information. The code is open source, and the documentation is available using this QR code. And GG also went to Rom France, who received a GR for this during this round.

So, in this case, the FI transactions are really, really cheap, but on the other hand, it's still a work in progress. We need to have it audited; it's research, so we're still working on it. And in the meantime, we were approached by Arbitrom, who were about to release their Orbit chain, which is L3, and we thought we'd give it a try with them. Today our next game will be released on an L3 Enitrus Orbit server. Enitrus is the implementation; it's DC.

We were heavily inspired by them. And the L2 server would be Arbit ROM One. But having your own channel presents many challenges, like having an indexer, finding solutions for an R (which is extremely difficult to achieve on small channels like this), having an R audience on PC, and so on. These are challenges that I think we'll be able to solve very soon. Well, listen, thank you very much.

[Applause] [Music]