Factory contracts deployment support

[smiasojed]

Factory Contracts & Bytecode Dependencies in Resolc

Overview

When using the resolc compiler, factory contracts that use the new keyword behave differently compared to traditional EVM. Understanding how to manage external contract bytecode is critical to ensuring successful deployments.

---

Key Difference from EVM

In traditional EVM environments:

• new Child(...) compiles to a CREATE opcode that embeds the full child contract bytecode in the transaction.

In resolc:

• new Child(...) compiles to a CREATE call that references a hash of the child contract’s bytecode.
• This means the child contract's bytecode must be uploaded beforehand, otherwise instantiation will fail.

---

Compiler Behavior

resolc analyzes the Solidity code and:

• Detects usage of new.
• Extracts and includes necessary factory dependencies in the output.

Example Output Snippet

{
  "factoryDependencies": {
    "0100001949af973d893f480abced5ef67da7704ff5e87db3a2df35bdf5e2fd10": "MyFactory.sol:Child"
  }
}

This indicates that the factory contract depends on a Child contract with that bytecode hash.

Bytecode Availability

Using the --standard-json compiler option, the output includes:

• Bytecode for all contracts (e.g., factory and children).
• The factoryDependencies field for deployment tools to process.

---

Deployment Process

A deployment tool (like Foundry) must:

1. Parse factoryDependencies.
2. Match each bytecode hash to the compiled child artifact.
3. Check if the hash is already deployed on-chain.
4. Upload missing dependencies.
5. Deploy the factory contract only after all dependencies are present.

---

Solidity Example

contract Child {
    uint public data;
    constructor(uint _data) {
        data = _data;
    }
}

contract Parent {
    function deployChild(uint val) external {
        // Only works if Child is pre-uploaded!
        Child c = new Child(val);
    }
}

⚠️ Note: The new Child(...) will fail if the corresponding bytecode hash has not been uploaded before.

---

To check

zksync additionally outputs factoryDependenciesUnlinked - to check if it is needed and do we need to align our compiler version

factoryDependenciesUnlinked":["MyFactory.sol:Child"] 

[xermicus]

We don't support linking yet. Once we do we will add unlinked factory dependencies too.

[soul022]

In Substrate’s contract model (as defined by pallet_revive ), uploading code and deploying (instantiating) a contract are two separate steps.

Uploading code (via upload_code) simply stores the contract bytecode on-chain under a code hash without creating a live contract account or running any [constructor logic]
(https://paritytech.github.io/polkadot-sdk/master/pallet_revive/pallet/enum.Call.html)

Whereas, deploying (instantiating) a contract (via instantiate or instantiate_with_code) not only ensures the code is present on-chain but also computes a new contract address, creates the contract account, and immediately executes the [constructor]
https://paritytech.github.io/polkadot-sdk/master/pallet_revive/pallet/struct.Pallet.html

So, deploying will trigger constructor execution, whereas uploading alone does not invoke constructors or create an active contract instance

[soul022]

In run function of "create.rs" used solang parser to parse solidity contract and check any contracts getting initialized inside the parent contract and extracting the contract name and path and generating the bytecode using the existing "remove_contract" function.

[soul022]

while using subxt,
metadata is required here subxt macro invocation
#[subxt::subxt(runtime_metadata_path = "revive_chain.metadata")]

taking inspiration from here : https://github.com/use-ink/cargo-contract/blob/master/crates/extrinsics/src/upload.rs