dapp deploy: Declarative IaC deployment tool

[ind-igo]

Let's spec out a dapp deploy tool. Here are notes from @gakonst and myself.

Context

Majority of smart contract deployment tools are based on procedural scripts. This mirrors old practices in compute infrastructure. Modern deployments are done via Infrastructure-as-Code (IaC) tools which allow you to define your deployment in declarative config files.

Goals

Goal of this project is to create a declarative IaC deployment tool for smart contracts that allows for consistent deployments. User should be able to describe the desired state of the deployment in a config file, and the tool should bring the current deployment to the desired state.

Existing solutions

dapp create
hardhat-deploy
Mars

Requirements:

• Yaml/json config file to declaratively define deployment
• Parse config into dependency graph
• Deploy all contracts according to graph order
• Execute post-deployment transactions in parallel

Questions:

• Example of how a deployment file might look?
• Should the current deployed state be saved?
  • If so, we can take a diff of current vs desired state and make changes accordingly.
  • Terraform and other IaC tools do this, but may be overkill for now.

[peetzweg]

Have been using hardhat-deploy only for now and it's so fragile and finicky. Best practices are not yet common knowledge nor enforced. It's insanely easy to break the deployment, deploy stuff you don't intended to redeploy and in general it's just hope for the best 🤞.

As with the great adoption of terraform for IaC, I desperately miss it for contract deployment. I already thought about implementing a terraform plugin myself lately for this. Working with insane spaghetti deploy scripts, I'm quite confident that terraform is not overkill.

Luckily terraform has a plugin based architecture and is open source. Developing a plugin with a provider and provisioner seems manageable.

https://learn.hashicorp.com/tutorials/terraform/provider-use

[gakonst]

We have released forge script which should address this, it's not declarative but is the deployment style we'll go for now https://book.getfoundry.sh/tutorials/solidity-scripting.html

[peetzweg]

We have released forge script which should address this, it's not declarative but is the deployment style we'll go for now https://book.getfoundry.sh/tutorials/solidity-scripting.html

Great to have solidity scripting in foundry. It looks pretty basic for now. For deploying a single NFT contract fine but i.e. compound? Will give it a proper use. 👍

The initial described "Declarative IaC deployment tool" hinted to me a terraform like experience - persisting the deployed state, figuring out what needs deployed or redeployed and applying proxy patterns, all described in an abstracted way from the actual smart contract language. Thinking about it it's probably out of scope for foundry anyways.

[gakonst]

Check a Uniswap V3 deploy script here fro more complex scripting https://github.com/joshieDo/v3-core/blob/main/deploy/deploy.sol

[kinthaiofficial]

Declarative IaC for contract deployment is a gap that's been annoying for a while. The current forge script approach works but feels more like an escape hatch than a first-class deployment system.

A few patterns that have helped in practice:

// deployment/DeployAll.s.sol
contract DeployAll is Script {
    function run() external {
        DeployConfig memory cfg = loadConfig(vm.envString("DEPLOY_ENV"));
        
        vm.startBroadcast(cfg.deployer);
        
        // Idempotent: check if already deployed
        address proxy = cfg.registry.get("MyContract");
        if (proxy == address(0)) {
            MyContract impl = new MyContract();
            proxy = deployProxy(impl, cfg.admin);
            cfg.registry.set("MyContract", proxy);
        } else {
            // Upgrade if needed
            upgradeIfNeeded(proxy, cfg);
        }
        
        vm.stopBroadcast();
    }
}

The registry pattern (storing deployed addresses per environment) solves a lot of the state tracking problem. Combined with vm.envString for environment config, you get something close to declarative.

What's still missing is dependency ordering — if Contract B depends on Contract A's address, you have to manage that sequencing manually. Terraform-style dependency graphs would be ideal here.