Skip to content

Conversation

@BenSparksCode
Copy link
Contributor

Changes vs Arbitrum Atlas v1.6.1

  • Calldata gas is calculated as a function of the actual calldata bytes, passed to GasAccLib and the L2GasCalculator, instead of just the calldata length as a uint. This gives us the optionality to either just use the length, or analyse the zero to non-zero byte ratio.
  • The Arbitrum L2GasCalculator is more configurable now:
    • With the actual calldata bytes of 1) the standard metacall params and 2) the solverOp.data, being passed in, we can use countZeroBytesCalldata() from Solady to get the number of zero and non-zero calldata bytes. This seems useful as the empirical metacall data from Artbitrum one shows that the compression ratio is highly correlated to how much of the calldata is zero bytes.
    • initialGasUsed() now has 4 coefficients that can be adjusted:
    Y = A(zero bytes)(gasPerL1Byte) + B(non-zero bytes)(gasPerL1Byte) + R(perL2TxInArbGas) + C
    
    • getCalldataGas() now has 3 coefficients that can be adjusted:
    Y = A(zero bytes)(gasPerL1Byte) + B(non-zero bytes)(gasPerL1Byte) + C
    
  • An inline assembly helper _endOfMetacallArgs() has been added to calculate the index of the end of the standard metacall() calldata. This should be a very gas efficient calculation as it uses the last dynamic bytes field, dAppOp.signature, as an anchor point, which avoids any looping through solverOps etc. It is important to get the slice of calldata this way as opposed to just using msg.data because it prevents charging the winning solver for any extra calldata packed onto the metacall by a bundler.
  • In foundry.toml, optimizer_runs has been lowered from 50 to 8, to keep Atlas within the ~24.5 kb size limit. This may have a small impact on gas efficiency.

To Do

  • A longer term solution is needed in GasAccLib, in solverOpCalldataGas() where the gas per byte of the static solverOp calldata is estimated assuming the ratio of zero to non-zero bytes is similar to that of the dynamic solverOp.data part. This may not be a reliable assumption.
  • In the Simulator, in any functions that take a single SolverOperation calldata param should be refactored to take a SolverOperation array with that single SolverOperation as the only item in the array. This would let us keep the SolverOperation in calldata instead of copying it into a memory form, which then requires separate versions of some of the gas accounting functions for calldata and memory.
  • Simulator should be refactored and cleaned up in general.
  • The Arbitrum L2GasCalculator needs to be rigorously tested, especially around the ability to robustly count zero vs non-zero calldata bytes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants