<style> .reveal { font-size: 36px; } </style> # Rounding Errors in Compute Opcodes ## ACDE \#223 ### Maria Silva #### October 23rd, 2025 [Slides](https://notes.ethereum.org/@misilva/Hy6o1OLRgx) --- 🚩 ## Problem Compute opcodes are so much more **efficient** than the current pricing that **we cannot make them cheap enough** with integer gas --- 🧮 ### What are rounding errors? If an operation should cost 0.8 based on its benchmark performance, we need to round it up to 1 to get an integer gas cost. In this case we get a 20% error due to rounding -> we could fit 20% more of this operation if we were not rounding it. --- <!-- .slide: style="font-size: 28px;" --> ## Only after a 400Mgas/s anchor do we get to reasonably low rounding errors  *This plot shows the average rounding errors of compute operations for different anchors, using the same execution time estimates from EIP-7904* --- <!-- .slide: style="font-size: 28px;" --> ## This results in an average rounding error of 4% per transaction  *This plots shows the distribution of rounding error for opcode vs. transaction level rounding. This takes a sample of 1000 blocks, assuming a reprice of compute opcodes with a 50Mgas/s anchor and the estimated execution times from EIP-7904's empirical analysis* --- :hammer: ## Solutions ### Gas rebase vs. Fractional gas --- ### :one: Gas rebase - All gas-related parameters and variables are increased by a factor of 1000. - Block limits and targets move from million units to billion units. - Gas costs move from units to thousand units. --- ### :two: Fractional gas - Add a new counter to the EVM, `milli_gas_left`. - Gas costs are defined in `milli_gas` and internal EVM gas accounting is entirely carried out in `milli_gas`. - `milli-gas` is rounded at transaction level - Transaction fees, transaction gas limits, and block gas limits are still computed and verified using the current `gas_used` counter. - There are no changes to blob gas accounting, refunds, or call data gas accounting. --- :scales: ### Pros and cons - Fractional gas adds EVM complexity - A new variable is introduced - Rounded at transaction level is introduced - Gas rebase impacts UX - This is a hammer on hardcoded values - User and devs s will experience a 1000x increase in gas variables and gas limits --- :grey_question: ## Ask - Is there a solution that sounds clearly better? - Should we propose both EIPs for discussion in Glamsterdam or can we already choose one over the other? --- :bookmark_tabs: ## References - [Milli-gas draft PR](https://github.com/ethereum/EIPs/pull/10563) - [Gas rebase draft PR](https://github.com/ethereum/EIPs/pull/10583) - [EIP-7904: General Repricing](https://eips.ethereum.org/EIPS/eip-7904) - [Analysis notebook](https://github.com/misilva73/evm-gas-repricings/blob/main/notebooks/2.2-frac-gas-analysis.ipynb)