Ask
deriveDeployment should derive a suite with its declared dependencies on chain, so a contract whose constructor needs a dependency's code can be verified.
The gap, verified on main (b19a415)
RainDeployVerifyBase.deriveDeployment (src/abstract/RainDeployVerifyBase.sol:93) does four things in order: snapshot state, clear the derived address, deploy the creation code through Zoltu, revert the snapshot. Nothing puts the suite's dependencies on chain first. That contradicts what DeploySuite.dependencies is documented to be: the addresses that MUST already have code before the suite can be deployed.
So any constructor that needs a dependency's code reverts under derivation. OZ's UpgradeableBeacon constructor reverts BeaconInvalidImplementation when the implementation has no code. deriveDeployments also feeds RainDeployVerifyChain.checkDeployedOnSupportedNetworks, so the chain group hits the same revert.
Consumer hitting it
In S01-Issuer/st0x.deploy#379, StoxWrappedTokenVaultBeacon and the three beacon-set deployers all construct beacons over dependency implementations. testSnapshotInternallyConsistent fails with DeployFailed(false, 0x0) on suite stox-wrapped-token-vault-beacon@0_1_1. The trace reverts 0x847ac564, which is BeaconInvalidImplementation(0x0d99…), the wrapped vault implementation it depends on.
A consumer can't pre-deploy its way out. Deploying every suite first leaves each set deployer's child beacons at their CREATE addresses. Re-deriving that deployer at its cleared address then creates the same beacons again and collides: about 1.02B gas burned, then DeployFailed.
#379 works around it in setUp, marked as a stopgap. It vm.etches every suite's recorded runtime code at its recorded address, so no constructor runs. Fixing this issue is what lets that stopgap be removed.
Ask
deriveDeploymentshould derive a suite with its declareddependencieson chain, so a contract whose constructor needs a dependency's code can be verified.The gap, verified on
main(b19a415)RainDeployVerifyBase.deriveDeployment(src/abstract/RainDeployVerifyBase.sol:93) does four things in order: snapshot state, clear the derived address, deploy the creation code through Zoltu, revert the snapshot. Nothing puts the suite'sdependencieson chain first. That contradicts whatDeploySuite.dependenciesis documented to be: the addresses that MUST already have code before the suite can be deployed.So any constructor that needs a dependency's code reverts under derivation. OZ's
UpgradeableBeaconconstructor revertsBeaconInvalidImplementationwhen the implementation has no code.deriveDeploymentsalso feedsRainDeployVerifyChain.checkDeployedOnSupportedNetworks, so the chain group hits the same revert.Consumer hitting it
In S01-Issuer/st0x.deploy#379,
StoxWrappedTokenVaultBeaconand the three beacon-set deployers all construct beacons over dependency implementations.testSnapshotInternallyConsistentfails withDeployFailed(false, 0x0)on suitestox-wrapped-token-vault-beacon@0_1_1. The trace reverts0x847ac564, which isBeaconInvalidImplementation(0x0d99…), the wrapped vault implementation it depends on.A consumer can't pre-deploy its way out. Deploying every suite first leaves each set deployer's child beacons at their
CREATEaddresses. Re-deriving that deployer at its cleared address then creates the same beacons again and collides: about 1.02B gas burned, thenDeployFailed.#379 works around it in
setUp, marked as a stopgap. Itvm.etches every suite's recorded runtime code at its recorded address, so no constructor runs. Fixing this issue is what lets that stopgap be removed.