Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ActBook: Hevm section seems outdated #158

Open
mir-ikbch opened this issue Aug 9, 2023 · 2 comments
Open

ActBook: Hevm section seems outdated #158

mir-ikbch opened this issue Aug 9, 2023 · 2 comments

Comments

@mir-ikbch
Copy link

I tried the example in Hevm section of ActBook.

The command in the book

act hevm --spec src/simple.act --soljson out/dapp.sol.json

did not work because --soljson option seems outdated and also it should have --contract option.
Then I tried

act hevm --spec xxx.act --sol xxx.sol --contract Simple

but I got the following:

Checking if constructor results are equivalent.
Found 1 total pairs of endstates
Asking the SMT solver for 1 pairs
Reuse of previous queries was Useful in 0 cases
Not equivalent.

-----

The following input results in different behaviours
Calldata:
  Any

Transaction Context:
  CallValue: 0x0

I thought this was because the second line of EVM should have been uint val = 0;, so I replaced it, but then I got

Checking if constructor results are equivalent.
Found 1 total pairs of endstates
Asking the SMT solver for 0 pairs
Reuse of previous queries was Useful in 0 cases
No discrepancies found
Checking if constructor input spaces are the same.
Not equivalent.

-----

The following inputs are accepted by Act but not EVM
Calldata:
  Any

Transaction Context:
  CallValue: 0x2

Now I have no idea why this is happening.

@zoep
Copy link
Collaborator

zoep commented Aug 14, 2023

Thanks for opening the issue! Indeed, the recently rewrote the hevm equivalence checker and the documentation is out of date.

The reason why the example is failing is because, for the moment, the constructor code is executed with an abstract store, so there is no information the the value of val is 0.

This might change in the future, but for now if you want the example to succeed you add an explicit constructor:

    constructor () payable {
	val = 0;
    }

@zoep
Copy link
Collaborator

zoep commented Aug 14, 2023

#159 should fixes this issue as it uses an empty initial store for constructors.

Note that the tests will still fail unless you add a precondition that callvalue is zero in the constructor:

interface constructor()

iff
  CALLVALUE == 0
  
creates
  uint val := 0

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

No branches or pull requests

2 participants