Initial address incompatibility

[exp-table]

I noticed that the sequence of addresses assigned to contracts deployed in any test is not identical to the one produced by dapptools.

In my case, it breaks a particular case where I generate a merkle tree with the addresses of custom User contracts. Their respectives proofs are hardcoded. Thus, the proofs ingested by some functions are therefore invalid.

@brockelmore and @gakonst suggested that the reasons are probably the initial address and the nonce(s).

[mds1]

If I'm understanding this issue correctly, then @gakonst we saw this a while back when you tried to verify foundry against the Drai repo, since there's a hardcoded address validation test here. That test passes on dapptools but failed against foundry, so it might be another useful reference to test against

[gakonst]

Yep, same issue @mds1

[brockelmore]

does anyone know the dapptools initial address? easiest to just match that as default to maintain max compatibility

[transmissions11]

It's in the hevm README I'll dig it up in a sec

[brockelmore]

looks like its 0x00a329c0648769a73afac7f9381e08fb43dbea72

[ghost]

@exp-table Interested to see how you use dapp.tools to test a merkle tree. Could you share the repo?

[transmissions11]

0x00a329c0648769a73afac7f9381e08fb43dbea72

yup https://github.com/dapphub/dapptools/tree/master/src/hevm#environment-variables

[brockelmore]

ah interesting issue here: i think the real issue is the address of the test contract, not the sender. See here. I tried on @exp-table's repo setting the sender variable to the above, and it still failed.

The hard part is that we support multiple test contracts. Which is the right thing to do for parallelizing tests, but means that we can't easily support without some compromises. One option is to not pre-deploy, and just deploy per test, and in run_test do a set_code into the specified address, which is what i imagine hevm does under the hood

[brockelmore]

Work around for anyone stumbling upon this and needs a short term fix:

contract Test {
    function setUp() public {
        vm.startPrank(<expectedAddress>);
        DeterministicContractAddress contract = new DeterministicContractAddress();
    }
}

use the startPrank cheatcode in your setup function prior to deploying any subsequent contracts. This may be the preferred long term solution

[fmhall]

Interestingly, setting DAPP_TEST_CALLER and DAPP_TEST_ADDRESS sets the addresses, but to different ones than I specified

[onbjerg]

Interestingly, setting DAPP_TEST_CALLER and DAPP_TEST_ADDRESS sets the addresses, but to different ones than I specified

DAPP_TEST_CALLER is (mistakenly) not used by Forge, it uses DAPP_TEST_ADDRESS to set the sender (see #253). If you set DAPP_TEST_ADDRESS to 0x00a329c0648769a73afac7f9381e08fb43dbea72 then the first test contract address will match dapptools

[onbjerg]

Hmm, this seems to not have been fixed anyway, which is strange. The sender is correct, but now the test contract address is always incorrect (not even the first one matches)

[gakonst]

You are right, it is still happening. Unsure / haven't debugged.

[onbjerg]

Figured out the issue, it seems that the dapptools address is from nonce 1 of the 0x00a329c0648769A73afAc7F9381E08FB43dBEA72 account whereas we deploy the contract at nonce 0.

PR #446 fixes it