[PARKED] Use uninterpreted functions for 2-phase solving approach - #996
[PARKED] Use uninterpreted functions for 2-phase solving approach#996gustavo-grieco wants to merge 136 commits into
Conversation
msooseth
left a comment
There was a problem hiding this comment.
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!
|
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! |
|
Keep in mind that abstract arithmetics are not enabled by default, I don't know if we should enable it for all the test 🤔 |
6bf8f15 to
dc02430
Compare
msooseth
left a comment
There was a problem hiding this comment.
Just two notes about what times out without this abstraction-refinement. The tests actually prove they time out
|
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. |
# 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>
|
Replaced by #1075 |
Description
A crude prototype for #995 The system now does 2-phase solving. It can now deal with these two ABDK verification problems:
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