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
What actually happens is before the actual deploy transaction is passed to the zksync operator, hardhat-deploy builds the factoryDepths. see. The problem is in this function, because for our contracts, factoryDepths array would only contain a single bytecode(Test1Bytecode), because it doesn't recursively goes through with artifacts. The deployment of Main works fine, but once you do the following steps after deployment:
get Main's address and call start on it. It will deploy Test1 and store it on addr. Get this addr value.
Then call start on that addr which would deploy Test2.
Call x on the Test2.
This will fail with the code hash is not known. This is actually expected, because deployment transaction's factoryDepths didn't contain the bytecode of Test2.
If you look into the original package from zksync, you will realize that factoryDepths is correctly constructed. See. You can see that it recursively goes through artifacts to generate the correct factoryDepths. In this case, factoryDepths would contain bytecodes of Test1 and Test2 and we wouldn't get the same problems anymore.
versions
hardhat-deploy 0.11.26 (but it also fails with latest version)
hardhat 2.12.4
nodejs 18.19.1
I wonder if this problem has been missed and why factoryDepths construction is not recursive in hardhat-deploy package.
@mikemcdonald made the PR with the extractFactoryDepths written in a wrong way in my opinion. What's your thoughts ? @wighawag
The text was updated successfully, but these errors were encountered:
I unfortunately do not know the intricacies as you seems to understand and I don't have the bandwidth to look at it. Do you think you could make a PR to fix it ?
Describe the bug
As we know, zksync introduces
factoryDepths
field in the transaction to make sure bytecodes are known.Assume the following contracts:
Inside
hardhat-deploy
script, let's assume we deploy theMain
contract.What actually happens is before the actual deploy transaction is passed to the zksync operator, hardhat-deploy builds the factoryDepths. see. The problem is in this function, because for our contracts,
factoryDepths
array would only contain a single bytecode(Test1Bytecode), because it doesn't recursively goes through with artifacts. The deployment ofMain
works fine, but once you do the following steps after deployment:Main
's address and callstart
on it. It will deployTest1
and store it onaddr
. Get thisaddr
value.start
on thataddr
which would deployTest2
.x
on the Test2.This will fail with
the code hash is not known
. This is actually expected, because deployment transaction's factoryDepths didn't contain the bytecode of Test2.If you look into the original package from zksync, you will realize that factoryDepths is correctly constructed. See. You can see that it recursively goes through artifacts to generate the correct factoryDepths. In this case,
factoryDepths
would contain bytecodes of Test1 and Test2 and we wouldn't get the same problems anymore.versions
I wonder if this problem has been missed and why factoryDepths construction is not recursive in
hardhat-deploy
package.@mikemcdonald made the PR with the
extractFactoryDepths
written in a wrong way in my opinion. What's your thoughts ? @wighawagThe text was updated successfully, but these errors were encountered: