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

Collision in address is "possible" as per hevm, even though it's not #549

Open
zoep opened this issue Sep 5, 2024 · 1 comment
Open
Labels
bug Something isn't working

Comments

@zoep
Copy link
Collaborator

zoep commented Sep 5, 2024

Should hevm enforce freshness conditions on newly created symbolic addresses?

I am working with this example:

contract A {
    uint public x;

    constructor ()  {
	x = 42;
    }
}

contract B {

    A a1;
    A a2;

    constructor() {
	a1 = new A();
	a2 = new A();
	assert (address(a1) != address(a2));
    }
}

running hevm symbolic --sig "B()" --code <the-creation-code> returns

Discovered the following counterexamples:

Calldata:
  0x32e7c5bf

Storage:
  Addr SymAddr "entrypoint": [(0x0,0x0),(0x1,0x0)]
  Addr SymAddr "miner": []
  Addr SymAddr "origin": []

Transaction Context:
  TxValue: 0x0

the same happens with --initial-storage Empty.

Removing the assertion results in QED.

@msooseth msooseth changed the title Should hevm be able to prove this? Collision in address is "possible" as per hevm, even though it's not Sep 9, 2024
@ethereum ethereum deleted a comment from zoep Sep 9, 2024
@msooseth msooseth added the bug Something isn't working label Sep 9, 2024
@msooseth
Copy link
Collaborator

msooseth commented Sep 9, 2024

Aliasing bug

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants