feat(avm): Track gas usage based on memory accesses#5518
feat(avm): Track gas usage based on memory accesses#5518spalladino wants to merge 1 commit intopalla/avm-fixed-gas-cost-instructionfrom
Conversation
|
Warning This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
This stack of pull requests is managed by Graphite. Learn more about stacking. Join @spalladino and the rest of your teammates on |
Benchmark resultsMetrics with a significant change:
Detailed resultsAll benchmarks are run on txs on the This benchmark source data is available in JSON format on S3 here. Values are compared against data from master at commit L2 block published to L1Each column represents the number of txs on an L2 block published to L1.
L2 chain processingEach column represents the number of blocks on the L2 chain where each block has 16 txs.
Circuits statsStats on running time and I/O sizes collected for every circuit run across all benchmarks.
Tree insertion statsThe duration to insert a fixed batch of leaves into each tree type.
MiscellaneousTransaction sizes based on how many contract classes are registered in the tx.
Transaction size based on fee payment method
Transaction processing duration by data writes.
|
Tracks gas usage for all AVM instructions based on memory consumption. Adds an optional wrapper for TaggedMemory (enabled on test only) that tracks all memory reads and writes to validate that the number of memory operations charged match the actual ones. Replaces existing #5514 and #5518 in favor of a more explicit approach, at the expense of more duplicated code in each instruction, but flattening the instruction hierarchy. Closes #5518 Closes #5514

Defines gas cost for each instruction based on its memory accesses: reads, indirect reads (priced as 2 reads), writes. Each instruction defines its expected number of memory operations, and gas cost is computed based on that and a base gas cost defined in the gas cost table. There is an additional check after the instruction is run that verifies that the number of memory operations matches the ones declared by the instruction. Note that, since we need to charge gas before execution (as specified in the yellow paper), we cannot just track accesses during execution and then charge that.
The new workflow for an instruction, which no instruction needs to fully override, is:
loadInputsto load from memory the inpiuts needed for execution (not needed if ops can compute their gas cost from their wires only)memoryOperationsto compute thememoryGasCost(defaults to zero)gasCostbased on the loaded inputs, using the sum ofbaseGasCostandmemoryGasCost(no need to override unless there's an additional gas component)internalExecute(all instructions override)This needs a bunch more tests, but I can add them in a subsequent PR.