Deploying many large interacting contracts

[elizabethdinella]

I am trying to write tests for the AvvenireAuction contract.

AvvenireAuction interacts with an externally deployed contract AvvenireCitizens.

AvvenireCitizens interacts with 2 externally deployed byte code contracts.

To deploy the bytecode contracts, I paste the bytecodes in my config using deployBytecodes at the addresses 0x9559067eBb005c002EAd3CD0e09D97C39177ba34 and 0x8F4d063621DDE21d17129c68174a90A67aFC74Fa.

When I execute the constructor below, echidna hangs indefinitely.

constructor() {
        address dataContractAddress = 0x9559067eBb005c002EAd3CD0e09D97C39177ba34;

        citizens = new AvvenireCitizens("AvvenireCitizens", "AVC", "https://av.mypinata.cloud/ipfs/QmYwCridML3Qo3vGSR2QrCs2rvofrTcyL2hd1z9AXqSduN/", 
                                       "",  dataContractAddress, 0x8F4d063621DDE21d17129c68174a90A67aFC74Fa);

        auction = new AvvenireAuction(2, 5000, 1000, 100, address(citizens));
    }

Alternatively, I explored deploying AvvenireCitizens using the deployContracts flag. However, AvvenireCitizens takes constructor arguments. How can I specify those in the config?

[gustavo-grieco]

I'm trying to reproduce this issue, I haven't finish yet, but it seems that using codeSize: 0xffffffffff in the config file allow me deploy AvvenireCitizens, but I'm still working on the other ones.

[elizabethdinella]

Hi, just checking, is there any update on this?

[gustavo-grieco]

I will have some time to finish investigating this next week. Sorry for the delay! :slightly_smiling_face:

[gustavo-grieco]

It seems that at least one of the contracts, the one deployed at 0x9559067eBb005c002EAd3CD0e09D97C39177ba34 fails when redeployed inside Echidna using its bytecode.

echidna-test: Deploying the contract 0x9559067eBb005c002EAd3CD0e09D97C39177ba34 failed (revert, out-of-gas, sending ether to an non-payable constructor, etc.)

without source code or more information about this contract, it is impossible to debug, I'm afraid.

[gustavo-grieco]

Same with the other one at 0x8F4d063621DDE21d17129c68174a90A67aFC74Fa.

[elizabethdinella]

Ah okay, so there is some require failing in the byte code? (Rather than something wrong with the way I am deploying the byte code)

[gustavo-grieco]

Yes, something inside that CREATE transactions is reverting. It could be a timestamp requirement, a lack of balance or an external call or something else :thinking:

[elizabethdinella]

Great, I had a suspicion this was the case. How did you figure this out? I was having trouble since the error message was vague.

echidna-test: Deploying the contract 0x9559067eBb005c002EAd3CD0e09D97C39177ba34 failed (revert, out-of-gas, sending ether to an non-payable constructor, etc.)

[brucdarc]

Also getting this on deploying a large contract system with echidna, is there any way to increase the gas limits?

echidna-test: Deploying the contract 0x00a329c0648769A73afAc7F9381E08FB43dBEA72 failed (revert, out-of-gas, sending ether to an non-payable constructor, etc.)

Im trying to deploy many large contracts from inside the constructor of my echidna test, however since it's run locally there should be some way to just have it ignore gas limits/ increase the block gas limit right?

I've confirmed this comes from gas cost in the constructor with an arbitrarily large for loop of an operation that executes successfully.

[gustavo-grieco]

If the contract is very large, you should using codeSize: 0xffffffffff. Otherwise, perhaps reverts for another reason. Please try #871

[Silur]

Please try #871

How?

[elopez]

Please try #871

How?

the change in #871 has been merged, if you install the latest echidna version (2.0.5) it should be included in it 👍

[Silur]

okay but there's no documentation on how to enable this feature, and I didn't manage to dig it out from the haskell code :)

I'm using 2.0.5 inside docker but still lacking revert reasons on deployment fails so I guess this is an opt-in flag

[gustavo-grieco]

Luckily, there is no need to enable anything. You should see the revert reason when the deployment fails. If there is no revert reason, then your reverts do not contain reason strings (e.g. revert(false), instead of revert(false, "reason));

[gustavo-grieco]

@elizabethdinella can you try using the state network forking feature from 2.1.0?

[gustavo-grieco]

Closing this one, please reopen if something is wrong.