feat(protocol): update `gasTargetPerL1Block`

[davidtaikocha]

Since we updated the L2Block.gasLimit to 300M, we need to update gasTargetPerL1Block in TaikoL2 too.

[openzeppelin-code[bot]]

feat(protocol): update gasTargetPerL1Block

Generated at commit: 176c29a90774d2afe76a6b0158d0beab14aa8ded

🚨 Report Summary

	Severity Level	Results
Contracts	Critical High Medium Low Note Total	2 2 0 3 41 48
Dependencies	Critical High Medium Low Note Total	0 0 0 0 0 0

---

For more details view the full report in OpenZeppelin Code Inspector

[Brechtpd]

This is big decision! Bigger blocks have little impact on the network except some smaller things, raising the gas target actually increases the capacity of the network 10x! So now nodes need to be able to handle 10x the throughput!

I would personally not raise this limit, at least not right now. And if we do increase it, would do it gradually so we can see the network is handling everything ok. This approach was also proposed by Peter from geth to increase the L1 capacity, and it seems like the safest thing to do. Also I don't think we'll need this extra capacity in the initial months anyway so I would not rush this. 10x is also on the upper edge for sure of what is even feasible as far as I know without running into different issues.

[dantaik]

This is big decision! Bigger blocks have little impact on the network except some smaller things, raising the gas target actually increases the capacity of the network 10x! So now nodes need to be able to handle 10x the throughput!

I would personally not raise this limit, at least not right now. And if we do increase it, would do it gradually so we can see the network is handling everything ok. This approach was also proposed by Peter from geth to increase the L1 capacity, and it seems like the safest thing to do. Also I don't think we'll need this extra capacity in the initial months anyway so I would not rush this. 10x is also on the upper edge for sure of what is even feasible as far as I know without running into different issues.

There are two factors we need to talk about. The block space and the block's size.

On L1, because of a constant 12-second block time, 15MillionGas (as block space) is made available every 12 seconds. But this is not true on Taiko L2.

It's reasonable to assume Taiko can scale Ethereum by 10x in terms of throughput (= block space). Then we need to make sure over a period of time after mainnet launch, we sell 10x block space than Ethereum. But Taiko has a variant block time, so the block gas limit on L2 does not translate into block space directly. We have to relay on base fee adjustment to ensure that if more space are sold than we planned, the basefee will go up, otherwise, it will go down. This is how 1559 works.

In this PR, David is trying to set the target block space to be sold to 10x the Ethereums. It has nothing to do with block gas limit.

Now lets talk about Taiko block gas limit. If we assume Taiko's block gas limit is the same as Ethereum (30 million gas), then if we still believe Taiko can scale Ethereum by 10x, then on average, in each Ethereum block, there will be 10 Taiko block proposed. Without blob reuse, there will be 10 blobs created and each of them is only partially used. We can chose to increase our gas limit correspondingly by 10x so we only need to propose one Taiko block per Ethereum block, assuming the 128K blob is large enough to encode all transactions.

We can even increase Taiko's block gas limit to 20x of Ethereum's block gas limit, ending up 1 Taiko block is proposed every 2 Ethereum block, if oen blob can encode all these transactions. The point is, with variable block time, it's up to the proposer, not use, to decide if they want to propose more frequently with small blocks and a lot of blob space wasted, or they want to aggregate txs into a very large block for cost-efficency. Increasing Taiko's block gas limit maximize the range of options.

BTW, it seems StartNet and zkSync doesn't even have block gas limit (correct me if I'm wrong, I asked ChatGPT), someone can build a block as long as the ZK can handle it. The total block space on L2 is more important than the block gas limit.

Therefore, I propose that we change TaikoL2's gasTargetPerL1Block to 10x Ethereum's value and Taiko L2 block's gas limit to 25x the Etheruem 's value -- as long as this is not an issue with zkVM

[Brechtpd]

It's reasonable to assume Taiko can scale Ethereum by 10x in terms of throughput (= block space).

I'm not sure why this is would be a reasonable assumption!

There isn't really anything Taiko does that makes a single L2 scale better than Ethereum L1 on its own. It's exactly the same chain. The only way to to scale more is to increase the hardware requirements to run a node. So if Taiko does 10x the gas limit of Ethereum, the node requirements are also 10x. The state growth is also 10x. All problems Ethereum has are amplified 10x. Something that takes a decade on Ethereum L1 to become a problem? That is now a single year when doing 10x the limit. Some good resources will be coming out from paradigm on this, the first one is already out: https://www.paradigm.xyz/2024/03/how-to-raise-the-gas-limit-1. Here is the tweet I mentioned above from Peter on how he thinks the gas limit should be increased because he is vocal about these problems: https://twitter.com/peter_szilagyi/status/1764918668486422968?t=Mvc1AUtDO2KZ16C9DS0qgg

Probably the best point of reference is binance chain to see how far geth can be pushed. Currently the gas target there seems to be 140M gas, which is similar to what this PR is trying to do. They had a lot of problems before pushing geth to its limits and they had to modify geth (in a bad way) to be able to push the gas target to this value, but I am not up to date with their latest changes or problems. I did find their recommended node specs: https://docs.bnbchain.org/docs/validator/best-practice/. You can see that the node requirements are very high as expected!

I don't think we need to target the same hardware requirements for nodes as Ethereum. But 10x just seems very high and even above the limit of binance chain which is not exactly seen as decentralized network because of these very high node requirements and the trouble to even be able to sync with the chain and keep up with the tip of the chain. If Taiko wants to be seen as a reasonably decentralized network where anybody can at least run a node (important for e.g. users wanting to exit the rollup), I think this is not the way to go.

On L1, because of a constant 12-second block time, 15MillionGas (as block space) is made available every 12 seconds. But this is not true on Taiko L2.

But Taiko has a variant block time, so the block gas limit on L2 does not translate into block space directly. We have to relay on base fee adjustment to ensure that if more space are sold than we planned, the basefee will go up, otherwise, it will go down. This is how 1559 works.

I am very well aware of how Taiko and EIP 1559 works. I am so aware that it was even me that proposed Taiko working this way! I am also very aware of the difference between the block gas limit and the gas target because I do indeed understand how blockchains work luckily!

In this PR, David is trying to set the target block space to be sold to 10x the Ethereums. It has nothing to do with block gas limit.

Which is the exactly the point I made? David's comment suggested that raising the block gas limit means that we should also increase the gas target which is exactly what I disagreed with!

Now lets talk about Taiko block gas limit. If we assume Taiko's block gas limit is the same as Ethereum (30 million gas), then if we still believe Taiko can scale Ethereum by 10x, then on average, in each Ethereum block, there will be 10 Taiko block proposed.

I do not assume Taiko can scale Ethereum 10x in a single node instance. This is why we need horizontal scalability with multiple L2s to be able to really scale Ethereum in a way that does not simply push node and hardware requirements to their limit. At least with how Ethereum currently works.

Without blob reuse, there will be 10 blobs created and each of them is only partially used. We can chose to increase our gas limit correspondingly by 10x so we only need to propose one Taiko block per Ethereum block, assuming the 128K blob is large enough to encode all transactions.

Like I also mentioned on discord, the block gas limit does not limit the efficient use of blob space. But it is not relevant to this discussion. I do not have anything against high block gas limits.

We can even increase Taiko's block gas limit to 20x of Ethereum's block gas limit, ending up 1 Taiko block is proposed every 2 Ethereum block, if oen blob can encode all these transactions. The point is, with variable block time, it's up to the proposer, not use, to decide if they want to propose more frequently with small blocks and a lot of blob space wasted, or they want to aggregate txs into a very large block for cost-efficency. Increasing Taiko's block gas limit maximize the range of options.

Yes I also wrote about this on discord about how blocks could be built, but not relevant to the discussion about the gas target limitation.

BTW, it seems StartNet and zkSync doesn't even have block gas limit (correct me if I'm wrong, I asked ChatGPT), someone can build a block as long as the ZK can handle it. The total block space on L2 is more important than the block gas limit.

Like I said above, I do not think there are is any problem with having very large block gas limits. This PR also has nothing to do with the block gas limit. Like previously discussed, I am okay with high block gas limits if they are not a problem for the node or the provers.

For gas target limitations, Starknet and zkSync are not really good references because they are not Ethereum equivalent, are not running the same Ethereum node software and do not share the same design as Ethereum, so the limitations of their chains can be quite different.

Therefore, I propose that we change TaikoL2's gasTargetPerL1Block to 10x Ethereum's value and Taiko L2 block's gas limit to 25x the Etheruem 's value -- as long as this is not an issue with zkVM

I do not understand this conclusion! I don't see any arguments that says why the gas target can be increased to 10x, because it just assumes it can be done. Only arguments are brought up why a high block gas limit is nice, and I mostly agree with those (minus some details). But I certainly agree that it has nothing to do with the gas target which is what this PR is about, which is the whole point of my initial answer!

[dantaik]

Using this query:

--Error: Unable to fully debug query 
SELECT
  SUM(gas_used) AS total_gas_used_last_year
FROM
  optimism.blocks -- replace optimsm with ethereum, arbitrum
WHERE
  time >= CAST('2024-03-15 00:00:00' AS timestamp) - INTERVAL '1' year

We can find on Dune the total amount of gas used in these 3 Ethereum equivalent blcokchains over the last 1 year:

• Ethereum: 39447702389902
• Arbitrum: 359211965700109 (9.10x)
• Optimism: 66250417068966 (1.67x)

Based on these numbers, I believe assuming that Taiko can handle 10x block space is not an unreasonable assumption.

I may not be as knowledgeable as you are, Brecht, but I think as a L2, if a chain's state becomes too large after a few years, the worst case scenario is that users can exit from the chain and migrate to a new chain with fresh state if state pruning is still not possible. This option is not there for L1, I believe that's the reason the gas limit per block on L1 must be carefully picked so that the state will not bloat any time soon so the core devs can "buy time" for solutions ("state expiry" or "state rent"). But as a L2, Taiko can be more aggressive.

[Brechtpd]

Arbitrum's numbers are interesting! I did not know that they were pushing things this hard. The minimum hardware requirements they list are also much lower than the one for Binance chain for some reason: https://docs.arbitrum.io/node-running/how-tos/running-a-full-node#minimum-hardware-configuration. They also list the current state growth values which should be good for another year or two I guess. I don't know why the hardware requirements are so different, both are based on geth, and the length at which the chain is running isn't able to explain this difference.

Based on these numbers, I believe assuming that Taiko can handle 10x block space is not an unreasonable assumption.

At 10x the gas numbers, you are effectively speed running the whole Ethereum blockchain of ~10 years in 6 months or so (gas limit was much lower for a long time) when this capacity is used fully. Which is big chain where archive nodes are not easy to run, so we really have to make sure that each part of Taiko's infrastructure can actually support this. If things break at 1x Ethereum, they will break even quicker and in even more and different ways at 10x Ethereum. So if we are not super comfortable now 1x, going to 10x is not going to make things better. It also seems unlikely this capacity would be used at lauch so not sure why we would have to rush this. Gradual increase still seems the way to go to me.

I may not be as knowledgeable as you are, Brecht,

It's not about knowledge, it's about arguments! If there are reasonable arguments and other data points, than of course that can change things. But they have to be known and written down.

but I think as a L2, if a chain's state becomes too large after a few years, the worst case scenario is that users can exit from the chain and migrate to a new chain with fresh state if state pruning is still not possible. This option is not there for L1, I believe that's the reason the gas limit per block on L1 must be carefully picked so that the state will not bloat any time soon so the core devs can "buy time" for solutions ("state expiry" or "state rent"). But as a L2, Taiko can be more aggressive.

There are multiple limitations I think and going on Peter from Geth, if they are not understood by the creator of Geth I would say it's as obvious it is without risk even if you take into account the higher hardware requirements. Exiting the chain would be possible for users, but only as long as running a node is still possible for the for security, and having to start a chain from scratch is also not the ideal scenario I guess.

[dantaik]

I propose to change the block space to 10x of Ethereum's so that the base fee on Taiko will be cheap enough to compete with other L2s. If we do run into the state-bloat issue, we can vote through DAO for reducing the block space for sale to slow down the state growth. To me, this is a nice problem to have, it at least means we have got quite some adoption. But if we set the block space to just 1x, then we may lose in the race during the first couple of years, and even if the chain can last tens of years from a technical perspective, no one will be willing to run a node.

[dantaik]

I propose to change the block space to 10x of Ethereum's so that the base fee on Taiko will be cheap enough to compete with other L2s. If we do run into the state-bloat issue, we can vote through DAO for reducing the block space to slow down the state growth. To me, this is a nice problem to have, it at least means we have got quite some adoption. But if we set the block space to just 1x, then we may lose in the race during the first couple of years, and even if the chain can last tens of years from a technical perspective, no one will be willing to run a node.

[Brechtpd]

If things work at 10x, then I'm all for it of course. And binance and it seems arbitrum have shown it can work, but of course it's not free and it's a tradeoff. People more knowledgeable than me are skeptic about the feasibility, so I think we have to be careful.

I'm really just proposing to take things slow! Even at 1x a lot of things are still untested and we simply don't know how well things will hold up, there will no doubt be issues to be ironed out. If we do 10x immediately I think it's risky because it just greatly increases the chance of things breaking even more in more ways. So if after a month we do the airdrop for example and suddenly the 10x throughput is being used, everything will be under extreme load and it wouldn't be the first chain to not be able to withstand this load even at far smaller throughput.

Is there something we lose by gradually increasing the gas target after mainnet in a couple of months and see where that takes us? As things are more tested, more mature, and we have more confidence in the different systems. To me this seems much safer. 10x is also more than what any other chain is currently doing, so we would literally go from 0 to 10x, running at speeds nobody is else doing in a completely new chain where people are still fixing issues each day and we have very little data to go on. I just think that's very risky and we should try to reduce risky things.

[Brechtpd]

I found some more information about arbitrum: https://docs.arbitrum.io/for-devs/chain-params

Their current gas target is 7M gas/second, which is 5.6x Ethereum. I think the dune figure may include multiple arbitrum chains, but I'm not sure about that. Still quite a lot higher than Ethereum, but not >9x.

It also doesn't explain the big difference in listed node hardware requirements between binance chain and arbitrum, so not really sure which one would be more accurate.

Their block gas limit is basically the same as Ethereum's because of fraud proof limitations.

[dantaik]

After second thought - considering the discussion above, and my research i'm also not in favor of a 10x. (1.5 - 2x shall be more than enough)

My arguments:

• We don't gain anything from that 10x but we can lose a lot. (Potential state bloat is just one of the issues - tho not the biggest one, becase parabolic state growth is not so realistic soon - see diagram below )
• Given the diagram below 2x shall be more than enough, Base is the only one which closes to ethereum but it is still below (Arbitrum Nove is technically not a rollup.. but it also 3x only in the last 24h)
• If we are 2x and the average is below that (which will be!) the baseFee will be low and we don't risk our network

Imagine an inscription-like surge or attack on Taiko.. We are at 10x, and the baseFee is still low, so basically pennies to flod the network.

So in a case (like airdrop and inscription-surge) it is a good thing (imo) to have a bottleneck (aka. slightly higher gas costs) which could eventually throttle the network a little bit -> so that we don't stress test th network 10x immediately.

Increasing it gradually might be a better approach.

My concern is that 2x may not show much difference during the first year or so and we may not be able to learn anything quickly (I think there are still things we can learn from the real data although there are quite some other research that we can follow already). If you are not comfortable with 10x, I propose to go 4-5x initially, and before we launch the DAO, we monitor the state growth speed and lower the value if necessary when we can still have the admin access.

[Brechtpd]

There's no need to keep the initial value for a full year I think. The value is easily be updated, so launching at 1x or 2x for safety/stability. Then see if everything is holding up and running stable for a couple of weeks, then increase by another 1x. Process can be repeated until some bottleneck is found which can then be mitigated or fixed or temporarily the throughput can be decreased again if it's difficult to fix.

I'm also worried about things like the monitoring tools, bridging infra, block explorers, guardian provers... not holding up, not just the node (though that is of course the most important one).

Another concern is also that nobody is running at 10x. Binance which is pushing things is at 9x. Arbitrum seemingly at 5.5x. There needs to be a reason for this because they would push things higher if they could, 10x may only be possible for a very short period of time before the chain gets too big to run at these speeds.

Or there is not enough activity, and then the difference between 10x and 2x doesn't matter anyway (except flatten peaks). We do have to take into account that with blobs L2 transactions can be a lot cheaper, so looking at historical data on how many transactions to expect may not be accurate because cheaper transactions no doubt will result in many more L2 transactions.

[dantaik]

@davidtaikocha if people see this problem differently, I suggest you close this PR for now.