Skip to content

[PARKED] Use uninterpreted functions for 2-phase solving approach - #996

Closed
gustavo-grieco wants to merge 136 commits into
mainfrom
poc-div-encoding
Closed

[PARKED] Use uninterpreted functions for 2-phase solving approach#996
gustavo-grieco wants to merge 136 commits into
mainfrom
poc-div-encoding

Conversation

@gustavo-grieco

@gustavo-grieco gustavo-grieco commented Jan 30, 2026

Copy link
Copy Markdown
Collaborator

Description

A crude prototype for #995 The system now does 2-phase solving. It can now deal with these two ABDK verification problems:

make verify-hevm T=prove_div_negative_divisor
make verify-hevm T=prove_div_values

Once abstraction-refinement is turned on. See this repo for details.

This change needs a flag to be set in the CLI for it to be enabled.

Checklist

  • tested locally
  • added automated tests
  • updated the docs
  • updated the changelog

Comment thread src/EVM/SMT/DivEncoding.hs Outdated
Comment thread src/EVM/Solvers.hs

@msooseth msooseth left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some thoughts and comments. I'm reluctant because:

  • There are all these axioms and they'll take time to review
  • I am not sure we need 3 phases

There are some thought-provoking parts here, though:

  • The improvement to the concrete SMT translation (i.e. even forgetting about all this abstraction)
  • The axioms may truly reflect that we have more information at hand than the SMT solver, and adding them may actually be sufficient, without the abstraction-refinement?

These 2 could actually be added as-is to the system, I think!

Comment thread src/EVM/Solvers.hs Outdated
Comment thread src/EVM/Solvers.hs Outdated
Comment thread src/EVM/SMT.hs Outdated
Comment thread src/EVM/SMT.hs Outdated
Comment thread src/EVM/SMT/DivEncoding.hs Outdated
Comment thread src/EVM/SMT/DivEncoding.hs Outdated
Comment thread src/EVM/SMT/DivEncoding.hs Outdated
@msooseth

msooseth commented Feb 2, 2026

Copy link
Copy Markdown
Collaborator

Can you also maybe fix the failures of the checks? I think it's failing only on warnings, so they should be easy to fix, and then we can see if the fuzz tests go through!

@gustavo-grieco

Copy link
Copy Markdown
Collaborator Author

Keep in mind that abstract arithmetics are not enabled by default, I don't know if we should enable it for all the test 🤔

@gustavo-grieco
gustavo-grieco marked this pull request as ready for review February 3, 2026 11:04
Comment thread src/EVM/SMT/DivEncoding.hs Outdated
@msooseth msooseth changed the title [RFC] Use uninterpreted functions for division Use uninterpreted functions for (S)Mod/(S)Div in a 2-phase solving approach Feb 10, 2026
@msooseth
msooseth force-pushed the poc-div-encoding branch 5 times, most recently from 6bf8f15 to dc02430 Compare February 16, 2026 16:36
@msooseth msooseth changed the title Use uninterpreted functions for (S)Mod/(S)Div in a 2-phase solving approach Use uninterpreted functions for 2+1-phase solving approach Feb 16, 2026
Comment thread src/EVM/SMT/DivEncoding.hs Outdated

@msooseth msooseth left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just two notes about what times out without this abstraction-refinement. The tests actually prove they time out

Comment thread test/test.hs
Comment thread test/test.hs
@msooseth msooseth changed the title Use uninterpreted functions for 2-phase solving approach [PARKED] Use uninterpreted functions for 2-phase solving approach Feb 23, 2026
@msooseth

Copy link
Copy Markdown
Collaborator

Let's park this for now. I wanna hear back from the Bitwuzla developers and I'm also a bit tired of trying to make this work :) We can come back to this another time.

gustavo-grieco and others added 9 commits April 6, 2026 12:18
# Conflicts:
#	test/clitest.hs
#	test/test.hs
The 2-phase refactor's sendScript requires every command to return "success",
which the empty solver (no-op process, no print-success) can't satisfy, so it
failed before check-sat; the merge from main added SMT content that exposed
this. Short-circuit EmptySolver in getOneSol to return Unknown with the same
message main produces (and that the 'empty solver is always unknown' CLI test
expects). The 'maybe it got killed' diagnostic stays on the real error paths.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Extend the abstraction+refinement div/mod encoding to unsigned Div/Mod,
mirroring the existing signed (SDiv/SMod) path:

- Declare abst_evm_bvudiv / abst_evm_bvurem uninterpreted functions and
  route Div/Mod through divModOp so they honor AbstractDivMod (the
  concrete path stays byte-identical via op2CheckZero).
- Split DivModKind into signed/unsigned variants so the absolute-value
  and sign-reconstruction machinery is never applied to unsigned
  operands, and signed/unsigned groups never share a congruence pool.
- For unsigned, the magnitude is the raw operand (no smtAbsolute) and the
  reconstruction is just the EVM divide-by-zero guard around the result
  var. The ground-truth axiom is zero-guarded
  (ite (= b 0) 0 (bvudiv a b)) to match EVM's x/0 = 0 semantics, since
  SMT-LIB's native bvudiv/bvurem return non-zero on a zero divisor.

Add unsigned tests to the Abstract-Arith group, including a
vault-preview-shares example (ERC-4626-style (assets << 64) / price) that
the shift-bounds encoding proves instantly but native bvudiv leaves at
"unknown".

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@gustavo-grieco

Copy link
Copy Markdown
Collaborator Author

Replaced by #1075

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants