You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The amount of Wasm code to verify here is quite large, so traditional verification approaches we've used for KEVM will not scale while keeping us in our modest budget. As such, we're taking this as the opportunity to develop more scalable/automated techniques.
After several discussions internally, we've landed on what seems like a feasible approach, broken into 3 phases.
Generate symbolic descriptions of the execution paths of the set_free_balance function automatically using fuzzing over concrete execution traces + abstraction/broadening ("poor person's" concolic execution). Call this SET-FREE-BALANCE-ACTUAL.
Prove that SET-FREE-BALANCE-SPEC is a refinement of SET-FREE-BALANCE-ACTUAL using KEQ tooling.
In our traditional approach, we would instead express SET-FREE-BALANCE-SPEC directly as a specification over the KWasm state, which is where the majority of the time would be spent. Instead, we'll try using (2) to auto-generate that description and save the human effort needed for that step, allowing us to focus on the high-level spec and the refinement relation.
Optional next step:
Ensure completeness of the generated traces. This would look like ALL_POSSIBLE_INITIAL_STATES == \/ lhs(GENERATED_RULES) (or perhaps the weaker ALL_POSSIBLE_INITIAL_STATES -> \/ lhs(GENERATED_RULES)), and if this formula is bottom, then we are complete.
The text was updated successfully, but these errors were encountered:
On the linked issue: #20 we are largely done with (1) other than bug-fixes/improvements. I'm in progress on (2), which is blocking (3). Demi and I have been pairing on (5), which is writing actual high-level properties over the spec developed in (1).
Recall that the summary is that (1) is about making a high-level model of the system, (2) is about generating specifications for the Wasm code that is generated, (3) is about proving that the generated specifications in (2) actually agree with the high-level model from (1), and (5) is about proving that the high-level model from (1) (and thus the low level model from (2)) actually has some desirable properties.
The amount of Wasm code to verify here is quite large, so traditional verification approaches we've used for KEVM will not scale while keeping us in our modest budget. As such, we're taking this as the opportunity to develop more scalable/automated techniques.
After several discussions internally, we've landed on what seems like a feasible approach, broken into 3 phases.
SET-FREE-BALANCE-SPEC
of theset_free_balance
function, capturing the intended behavior: Executable spec - initial high-level K files describing desired behavior #15.set_free_balance
function automatically using fuzzing over concrete execution traces + abstraction/broadening ("poor person's" concolic execution). Call thisSET-FREE-BALANCE-ACTUAL
.SET-FREE-BALANCE-SPEC
is a refinement ofSET-FREE-BALANCE-ACTUAL
using KEQ tooling.In our traditional approach, we would instead express
SET-FREE-BALANCE-SPEC
directly as a specification over the KWasm state, which is where the majority of the time would be spent. Instead, we'll try using (2) to auto-generate that description and save the human effort needed for that step, allowing us to focus on the high-level spec and the refinement relation.Optional next step:
ALL_POSSIBLE_INITIAL_STATES == \/ lhs(GENERATED_RULES)
(or perhaps the weakerALL_POSSIBLE_INITIAL_STATES -> \/ lhs(GENERATED_RULES)
), and if this formula is bottom, then we are complete.The text was updated successfully, but these errors were encountered: