Vyper Bounded Loops and EVM Gas Predictability

Question

Vyper enforces strict bounded loops to ensure that iteration counts are determinable at compile-time, preventing potential out-of-gas attacks and maintaining deterministic bytecode mapping.

While this constraint ensures safety, the interaction between nested bounded loops and evolving EVM gas pricing models introduces uncertainty. Specifically, as the EVM evolves across different versions, the gas overhead for managing these bounds and the resulting bytecode execution patterns may vary.

Given the fixed-size allocation strategy used by the Vyper compiler, it is unclear how gas predictability is maintained when complex nested loops are deployed across disparate EVM environments.

How does the Vyper compiler calculate gas estimation for nested bounded loops across different EVM versions?
  Is there a documented method to verify that nested loop gas costs remain constant regardless of the target EVM version?

Tasadduq Burney · Answer

Answer
Vyper requires every loop to have a compile‑time constant upper bound. The compiler evaluates that bound, multiplies it by the gas cost of the loop body (using the opcode‑gas table for the selected EVM version), and for nested loops multiplies the iteration counts together.
How Vyper estimates gas for nested bounded loops

The compiler checks each loop bound; if it is not a literal or compile‑time constant expression the contract fails to compile.
Once accepted, the compiler determines the exact number of iterations for each loop.
It looks up the gas cost of every opcode in the loop body from the table that matches the --evm-version flag (e.g., paris, shanghai).
The per‑iteration cost is multiplied by the iteration count; for nested loops the outer count is multiplied by the inner count before applying the per‑iteration cost.
Storage reads or writes inside the loop are treated as variable cost; the compiler adds a conservative worst‑case estimate for each SLOAD/SSTORE based on the same opcode table, but the loop structure itself remains deterministic.

Verifying that nested loop gas costs stay constant across EVM versions

Run vyper --gas-estimate contract.vy to get the estimate for the default EVM version.
Repeat the command with --evm-version set to each target version (e.g., vyper --gas-estimate --evm-version paris contract.vy).
Compare the printed estimates; because the loop bounds are compile‑time constants, any difference comes only from changes in the opcode gas table.
For a live check, deploy the compiled bytecode to a local node configured for the desired EVM version (e.g., Ganache with the appropriate chainId) and call the function. Record the gasUsed from the transaction receipt and compare it to the compiler’s estimate.
If the on‑chain gasUsed matches the estimate within the conservative margin, the gas cost is predictable for that EVM version.

Assumptions: You are using Vyper ≥0.3.0 and you explicitly set the EVM version when compiling. Storage accesses inside the loop can still cause runtime variability, so the estimate is a worst‑case bound.
Which EVM version are you targeting for your verification?

Vyper Bounded Loops and EVM Gas Predictability

1 answer

Answer

How Vyper estimates gas for nested bounded loops

Verifying that nested loop gas costs stay constant across EVM versions

Your perspective belongs here.

1 question comment

Nested Loop Gas Calculation in Vyper: EVM Version Dependencies