Reporting an integer_squareroot Bug in the Ethereum Consensus Specification
ESBMC-Python — the first publicly available BMC-based verifier for Python programs
(per ISSTA 2024 paper §4) — identified a division-by-zero in the
integer_squareroot
helper of the Ethereum consensus specification. The fix was merged upstream into
ethereum/consensus-specs.
PR #3600
Fix merged upstream into ethereum/consensus-specs (15 Feb 2024)
First
Publicly available BMC-based Python code verifier (per ISSTA 2024 paper §4)
ISSTA 2024
Published at ACM SIGSOFT ISSTA, Tool Demonstrations track
EF FY22-0751
Ethereum Foundation grant awarded to the University of Manchester BMC project team
Challenge
The Ethereum consensus specification is the Python reference that all Ethereum consensus-layer client implementations must follow. It governs node inclusion, validation, and validator penalty processes. Errors in this specification can propagate to every conformant client and, in the worst case, lead to availability issues or other operational disruption of the consensus layer.
The specification is written in Python. While prior formal-methods work had targeted parts of the Ethereum 2.0 beacon chain, no BMC-based verifier for Python had been publicly available — the only directly comparable tool (MSV) had no public source or reproducible artefacts. There was therefore no off-the-shelf bounded model checker to apply to the eth2spec Python codebase.
Approach
Our team led the development of ESBMC-Python, the first publicly
available BMC-based Python code verifier (per ISSTA 2024 paper §4). ESBMC-Python is
released as part of the open-source ESBMC project. It parses Python into an AST, performs
type inference (inserting AnnAssign
nodes with explicit type information), and then translates Python expressions and
statements into ESBMC's GOTO intermediate representation, where the existing
symbolic-execution + SMT-solving pipeline applies. Properties checked include
division-by-zero, arithmetic overflows, and assertion failures.
To apply ESBMC-Python to the Ethereum consensus specification (eth2spec), we extended
the front-end with custom types — uint64,
uint128, and
uint256 — and
verified each function individually with non-deterministic inputs.
The bug
def integer_squareroot(n: uint64) -> uint64:
x = n
y = (x + 1) // 2 # ← overflows to 0 when n = 2⁶⁴ − 1
while y < x:
x = y # x becomes 0 after the overflow
y = (x + n // x) // 2 # ← ZeroDivisionError: n // 0
return x
# Input: n = 2⁶⁴ − 1 (maximum uint64 value)
# Result: ZeroDivisionError — the unsigned integer overflows to 0,
# then is used as the denominator of a division operation.
# ESBMC-Python: confirmed the bug and produced a counterexample trace. Results
A division-by-zero in the integer_squareroot
helper of the eth2spec: an unsigned integer overflowed to zero after
being incremented and was later used as the denominator of a division operation
(per ISSTA 2024 paper §3.1).
The fix was merged upstream as ethereum/consensus-specs PR #3600 ("Handle integer_squareroot bound case", merged 15 February 2024). The PR description credits our team for reporting the issue.
The work was published as a Tool Demonstration at ACM SIGSOFT ISSTA 2024 and supported by Ethereum Foundation grant FY22-0751 ("Bounded Model Checking for Verifying and Testing Ethereum Consensus Specifications").
References
- Bruno Farias, Rafael Menezes, Eddie B. de Lima Filho, Youcheng Sun, Lucas C. Cordeiro. ESBMC-Python: A Bounded Model Checker for Python Programs. ISSTA 2024: 1836–1840. doi.org/10.1145/3650212.3685304
- ethereum/consensus-specs PR #3600. Handle integer_squareroot bound case. Merged 15 February 2024. github.com/ethereum/consensus-specs/pull/3600
Note. This page describes a published academic research engagement supported by the Ethereum Foundation under grant FY22-0751. Claims about the bug, the tool, and the verification methodology track the ISSTA 2024 paper; the upstream fix was merged via the linked GitHub pull request, where the Ethereum core team explicitly credits the project team. Network-level statistics about Ethereum's deployment footprint are not within the scope of the published paper and are not asserted here.