Skip to content

test(e2e): regression for BLS PoP precompile missing gas-limit check (audit #678)#740

Closed
keanji-x wants to merge 2 commits into
mainfrom
test/e2e-bls-precompile-gas-678
Closed

test(e2e): regression for BLS PoP precompile missing gas-limit check (audit #678)#740
keanji-x wants to merge 2 commits into
mainfrom
test/e2e-bls-precompile-gas-678

Conversation

@keanji-x

Copy link
Copy Markdown
Contributor

What

Adds an end-to-end regression suite gravity_e2e/cluster_test_cases/bls_precompile_halt/ for the BLS proof-of-possession precompile (0x00000000000000000000000000000001625f5001).

Why (gravity-audit #678)

The precompile (gravity-reth … bls_precompile.rs) returns a flat gas_used = 110_000 with no check against the forwarded gas. When a normal transaction calls it forwarding < 110_000 gas, the EVM dispatcher hits an unconditional assert!(record_cost(...)) (alloy-evm precompiles.rs:425) and the node panics deterministically"Gas underflow is not possible" — instead of an ordinary out-of-gas revert. Because the panic is in the deterministic block-execution path, every validator that executes the block dies (and re-dies on replay), i.e. a one-transaction, any-funded-account chain halt.

The test

  • Control (benign): a well-gassed call (gas=300000) must mine with gasUsed == 131576 (21000 intrinsic + 576 calldata + 110000 precompile) — proving the precompile is reached and charges the flat 110k.
  • Regression assertion: a low-gas call (gas=30000) must be a normal out-of-gas revert — the node must stay alive, keep producing blocks, keep the RPC responsive, and log no panic.

The regression assertion is marked @pytest.mark.xfail(reason="gravity-audit #678 …", strict=False), so:

  • today it is reported xfail (the node panics) → CI stays green while documenting the bug;
  • after the gas-limit guard lands it will xpass → remove the xfail marker to make it a hard regression guard.

Reproduction evidence (local single-node)

Control call mined in block 28, gasUsed=131576
Sending low-gas call (gas=30000)…
After low-gas call: samples=[37], rpc_failures=14, process_alive=False
Found panic marker -> /tmp/.../node1/logs/debug.log: Gas underflow is not possible
1 xfailed in 32.80s

Suggested fix (separate change)

Guard the cost before work in the precompile handler:

if POP_VERIFY_GAS > input.gas { return Err(PrecompileError::OutOfGas); }

(and the same pattern for the mint precompile). Once merged, this test flips to xpass.

Scope

Adds 3 files under one new suite dir; no production code changed. Generated artifacts/ are gitignored and regenerated by the runner (same convention as single_node).

Authorized security-audit deliverable. Tracking issue: Galxe/gravity-audit#678.

🤖 Generated with Claude Code

keanji-x and others added 2 commits June 10, 2026 14:25
…(audit #678)

Adds a single-node e2e suite that exercises the BLS proof-of-possession
precompile at 0x00000000000000000000000000000001625f5001.

The precompile returns a flat gas_used=110_000 with no comparison against the
forwarded gas, so a call that forwards <110_000 gas hits an unconditional
assert!(record_cost(...)) in alloy-evm and panics the node deterministically
("Gas underflow is not possible") instead of a normal out-of-gas revert.

The test asserts the CORRECT (post-fix) behavior — the node survives a low-gas
precompile call and keeps producing blocks — and is marked xfail referencing
gravity-audit #678 so CI stays green until the gas-limit guard lands, then
flips to xpass to prompt removal of the marker. A benign control call first
proves the precompile is reached (gasUsed == 131576 = 21000 + 576 + 110000).

Reproduced locally: control mines at gasUsed=131576; the low-gas call kills the
node (process exits, RPC unresponsive, panic "Gas underflow is not possible" in
debug.log) -> reported XFAIL.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@keanji-x

Copy link
Copy Markdown
Contributor Author

Closing per maintainer — the BLS PoP precompile gas-limit fix (#678) has just been merged, so this xfail regression suite is superseded.

For the record, the bug was reproduced deterministically against pre-fix builds: a call forwarding < 110_000 gas to 0x..1625f5001 made the precompile return a flat gas_used=110_000 with no gas-limit guard, underflowing alloy-evm's record_cost and panicking the node ("Gas underflow is not possible"). Verified twice — most recently against a freshly-built latest-main binary (control call mined at gasUsed=131576, low-gas call killed the node, panic in debug.log) → XFAIL.

If useful, the precompile-level e2e suite (well-gassed control proving reachability + low-gas killer) could be re-added as a passing regression alongside the fix to lock it in; happy to open that against the post-fix commit if wanted.

@keanji-x keanji-x closed this Jun 10, 2026
@keanji-x keanji-x deleted the test/e2e-bls-precompile-gas-678 branch June 10, 2026 08:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants