Skip to content

Chain-specific gas schedules design doc #298

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

niran
Copy link
Contributor

@niran niran commented Jul 16, 2025

  • design doc: multiple gas schedules
  • Update the gas schedule proposal to be chain-specific

@tynes
Copy link
Contributor

tynes commented Jul 16, 2025

Given that the optimal pricing changes based on throughput and state size, I think it makes more sense to have "sets" of costs rather than doing it on a per chain basis. You could imagine something like: "use this set if you state size is in this range and your throughput is in this range, use that set if your state size is in that range and your throughput is in that range". The reason why this is more appealing to me is that it gives an off the shelf solution that is likely good enough for chains in that range. It also increases the chances that smart contracts will just work across different chains and also more likely to be supported by various ecosystem developer tooling. I think a bigger change like multidimensional pricing is going to be necessary eventually to lessen the fact that optimal pricing changes based on throughput and state size. Curious what you think

@niran
Copy link
Contributor Author

niran commented Jul 17, 2025

Yeah, my initial proposal had presets for gas schedules, but I backed out of that a few reasons:

  1. Gas presets will have to be maintained indefinitely to process historical blocks, adding to our diff from upstream. Chain-specific gas costs also have to be maintained indefinitely, but the core logic needed to implement this is more likely to be merged into upstream than presets.
  2. Adding more custom gas costs later (e.g. for SSTORE) becomes harder to do since it would affect all chains using the same preset.
  3. When the entire gas schedule is repriced (as in EIP 7904), the gas presets would need to be updated as well. The rollup operators who are using a given preset would need to coordinate on new values.

I'm totally open to moving back to presets.

I think a bigger change like multidimensional pricing is going to be necessary eventually

I'm a big fan of multdimensional metering! It does look like when it becomes available, tweaking the limit for each resource will happen more often than tweaking the actual gas cost since the latter can cause more breakage.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants