Arbitrum/atlas v1.7 experimental #490
Draft
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Changes vs Arbitrum Atlas v1.6.1
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:getCalldataGas()now has 3 coefficients that can be adjusted:_endOfMetacallArgs()has been added to calculate the index of the end of the standardmetacall()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 usingmsg.databecause it prevents charging the winning solver for any extra calldata packed onto the metacall by a bundler.optimizer_runshas 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
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 dynamicsolverOp.datapart. This may not be a reliable assumption.