Conversation
|
|
||
| for i, tx := range segment.txes[startIndex:] { | ||
| if tx.Gas() > perBlockGasLimit { | ||
| if tx.Gas() > MaxPerBlockGasLimit() { |
There was a problem hiding this comment.
Let's use b.header.GasLimit here since that we can adjust it if we want to without changing multiple places in the code
There was a problem hiding this comment.
The idea here is that we want to apply the max block size rather than the current gas pool, because we're flat-out rejecting the tx if the condition is true. If a tx fits within the max block size but there isn't enough gas left for it in the current block, then we shouldn't reject the tx but should instead start a new block.
There was a problem hiding this comment.
This is actually trickier, for a few reasons.
(1) At this point in the code, tx.gas is the tx's original gas request minus the L1 gas charge. Just like in Classic, a tx sender won't be able to predict the L1 charge exactly, so it might be difficult for the sender to avoid asking for more than the max gas allowed. So maybe we should adjust tx.gas down to the max limit here, if it would otherwise be above the limit, like we did in Classic.
(2) If the tx's request is less than PerBlockGasLimit, but greater than the block's remaining gas pool, then the right step is to end the block, so that the current tx can go into the next block where there could be more gas pool available.
(3) But if we're in case (2) and it's also the case that ArbOS's gas pool is empty or near-empty, then the next block might not have enough gas available in its gas pool, so pushing to the next block won't help and we should congestion-reject the tx.
The upshot is that we're going to need to change the logic here. We can do that in this PR, or maybe a separate PR makes more sense because it's a separate design decision.
| numeratorBase := new(big.Int).Mul(big.NewInt(121), maxProd) | ||
| denominator := new(big.Int).Mul(big.NewInt(120), maxProd) | ||
|
|
||
| for i := uint64(0); i < secondsElapsed; i++ { |
There was a problem hiding this comment.
Is there a way we could get rid of this loop?
There was a problem hiding this comment.
We could reduce the number of iterations by jumping forward in chunks of say 15 seconds. I figured that wasn't worth the trouble since this only runs one iteration per wall-clock second.
There was a problem hiding this comment.
There's not a simple closed-form equation for the result of this loop, because of the combination of non-linear compounding and clipping of the gas pool amounts.
Implement memory.size and memory.grow
Module import-export self-linkage fix
…-verification-v2.3.1 Integration with Avail DA layer in Arbitrum nitro stack
Introduce Initial Validator Client Code
3 participants
Track the gas pool and adjust gas price according to the Arbitrum L2 gas pricing algorithm. This price will appear to clients as the EVM base fee.