fix(ethexe/ethereum): use gas limit from estimate_gas, add limit to max_fee_per_gas_in_gwei

[StackOverflowExcept1on]

No description provided.

[semanticdiff-com]

Review changes with  

Changed Files

File	Status
ethexe/ethereum/src/router/mod.rs	17% smaller
.ethexe.example.local.toml	Unsupported file format
.ethexe.example.toml	Unsupported file format
.github/workflows/PR.yml	0% smaller
.github/workflows/build.yml	0% smaller
ethexe/cli/README.md	Unsupported file format
ethexe/cli/src/params/ethereum.rs	0% smaller
ethexe/ethereum/src/lib.rs	Unsupported file format
ethexe/service/src/config.rs	0% smaller
ethexe/service/src/tests/utils/env.rs	0% smaller
ethexe/service/tests/smoke.rs	0% smaller

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request refines the gas limit estimation process for batch commitments. By replacing the previous max-based fallback with a direct estimation and an explicit validation step, the system now ensures that gas limits remain within acceptable bounds while providing better error reporting when limits are exceeded.

Highlights

• Gas Limit Calculation: Updated the gas limit logic to use the estimated gas limit directly instead of defaulting to a huge gas limit.
• Validation Logic: Added a validation check to ensure the calculated gas limit does not exceed the defined huge gas limit, returning an error if it does.

Ignored Files

• Ignored by pattern: .github/workflows/** (2)
  • .github/workflows/PR.yml
  • .github/workflows/build.yml

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request updates the gas limit calculation in the Ethereum router to explicitly check against HUGE_GAS_LIMIT and return an error if exceeded, replacing the previous logic that used a max operation. A review comment suggests simplifying the error message in the anyhow! macro to remove redundancy with the existing log entry.

[StackOverflowExcept1on]

@claude opus review

[claude]

Claude finished @StackOverflowExcept1on's task in 2m 31s —— View job

---

Claude PR Review

Summary: This PR replaces the previous HUGE_GAS_LIMIT.max(estimated + predecessor) with the estimated gas directly (plus a 30k buffer for blockIsPredecessor), and rejects the commit when that exceeds 10M. It also adds a configurable cap on the estimated EIP-1559 max_fee_per_gas (in gwei) — if enabled, the validator will refuse to submit a batch when the mempool is pricing gas above the ceiling. New config knob eip1559-max-fee-per-gas-in-gwei is wired through CLI → params → service config → Ethereum/Router.

Overall the direction is solid — tightening gas use and adding a fee ceiling for validator cost control is the right call. Comments below, ordered by severity.

---

severity: medium — loss of safety margin on submitted gas limit

File: ethexe/ethereum/src/router/mod.rs lines 412–421

Previously gas_limit = HUGE_GAS_LIMIT.max(estimated + 30_000), so ≥10M was always submitted. Now it's estimated + 30_000 exactly. eth_estimateGas returns the minimum gas needed for success under the simulated state (and here we simulate with a state override router.reserved = 1). Between estimation and inclusion, storage-slot warmth, access-list changes, validator set updates, or reverting on any state-dependent branch not hit during estimation can push actual usage above the estimate — the tx will then revert OOG.

The 30k buffer covers Gear.blockIsPredecessor specifically but leaves no headroom for anything else. Consider a small multiplicative buffer (e.g., estimated * 110 / 100 + 30_000) before the HUGE_GAS_LIMIT check, or make the buffer configurable. The existing 10M hard cap still protects against a pathological estimate.

Worth quantifying via a run on Sepolia with tight gas — if we observe no OOG reverts over N batches, the margin is fine; otherwise this will show up as flaky validator tx failures.

---

severity: medium — extra RPC round-trip on every batch commitment

File: ethexe/ethereum/src/router/mod.rs lines 391–397

estimate_eip1559_fees_with(...) fires a separate RPC (eth_feeHistory) per commit_batch_pending call, in addition to the existing estimate_gas. On validators committing every block this doubles the pre-send RPC chatter. Alloy already runs an estimator internally during send(), so the second call here is purely for the safety check.

Options: (a) skip the call entirely when eip1559_max_fee_per_gas_in_gwei == 0 (the disabled case) — trivial and handles the common path; (b) do the estimate once and also pass it to the builder via builder.max_fee_per_gas(...), so the fee the tx gets submitted with is the same one checked. Option (a) at minimum seems free.

if self.eip1559_max_fee_per_gas_in_gwei > 0 {
    let Eip1559Estimation { max_fee_per_gas, .. } = self
        .instance
        .provider()
        .estimate_eip1559_fees_with(self.eip1559_estimator.clone())
        .await?;
    // ... check ...
}

---

severity: low — misleading default in example configs

Files: .ethexe.example.toml line 124, .ethexe.example.local.toml line 124, ethexe/cli/README.md

# EIP-1559 max fee per gas in gwei for transaction fee estimation (for batch commitments).
# (optional, default: 20).
# eip1559-max-fee-per-gas-in-gwei = 20

The actual default resolved in code is NO_EIP1559_MAX_FEE_PER_GAS_IN_GWEI = 0 (see ethexe/ethereum/src/lib.rs:240 and ethexe/cli/src/params/ethereum.rs:84-85), which means check disabled. The default: 20 line in the comment is wrong — this will cause users reading the example to believe the cap is active out of the box when it isn't. Recommend # (optional, default: 0 — disabled; recommended: 20).

Contrast with eip1559-fee-increase-percentage where default: 15 is accurate (resolved via INCREASED_EIP1559_FEE_INCREASE_PERCENTAGE = 15).

---

severity: low — stray closing paren in error message

File: ethexe/ethereum/src/router/mod.rs line 408

return Err(anyhow!(
    "Estimated max fee per gas {max_fee_per_gas_in_gwei} gwei is higher than the configured maximum of {eip1559_max_fee_per_gas_in_gwei} gwei, refusing to commit batch)",
));

Trailing ) before the closing quote — looks like a copy/paste slip from the log::error! call above (which has (commitment: ...) earlier in the string). Cosmetic but will surface in user-visible error reporting.

---

severity: low — gwei truncation in the ceiling check

File: ethexe/ethereum/src/router/mod.rs line 398

let max_fee_per_gas_in_gwei = max_fee_per_gas / (GWEI_TO_WEI as u128);

Integer division floors, so a fee of e.g. 25.9 gwei becomes 25. If the user sets the cap to 25 gwei, a 25.9 gwei mempool price will slip through. Not a security issue (the intent is "roughly cap cost"), but worth either noting in the comment or switching to max_fee_per_gas.div_ceil(GWEI_TO_WEI as u128) for conservative rounding. Or — ceiling in wei directly and expose the knob as wei — removes the unit mismatch entirely.

---

severity: low — zero-as-disabled sentinel

File: ethexe/ethereum/src/lib.rs lines 240–241, ethexe/service/src/config.rs line 116

eip1559_max_fee_per_gas_in_gwei: u128 uses 0 to mean "no limit". Option<u128> (already the shape at the CLI/builder boundary) would be more explicit and remove the > 0 guard. Follows the existing NO_EIP1559_FEE_INCREASE_PERCENTAGE: u64 = 0 pattern though, so not worth fighting unless the whole family is revisited.

---

severity: low — unrelated workflow change in the same PR

Files: .github/workflows/PR.yml, .github/workflows/build.yml

Adds an E0-forcedocker label to trigger docker builds on PRs outside of release profile. Unrelated to the gas-limit fix; would be cleaner as a separate PR for reviewability and bisection.

---

Nit (agreed with gemini-code-assist): the anyhow! message at line 418–420 repeats most of the log::error! above. Since the log already carries commitment, the anyhow payload can just be "Estimated gas limit {gas_limit} is too high" — shorter and doesn't duplicate the commitment blob across two sinks when the error bubbles up.

---

Todo

• Read PR diff and changed files
• Review ethexe/ethereum/src/router/mod.rs changes (core gas limit fix)
• Review ethexe/ethereum/src/lib.rs changes (max_fee_per_gas limit)
• Review ethexe/cli/src/params/ethereum.rs changes
• Review config/example file changes
• Check style guide in .gemini/styleguide.md
• Post final review
  • Branch: av/ethexe-fix-gas-limit

[ecol-master]

The max_fee_per_gas = 0 means, that TX will never be included, because at least base_fee always > 0.

Did you mean max_priority_fee_per_gas = 0?

[StackOverflowExcept1on]

0 means limit is disabled by default