★ FEATURED ARTICLE 写Solidity写到后面你会发现一个分水岭新手在调函数老手在设计合约之间的协作方式。尤其是当你开始做工厂、聚合层协议、多链部署这类事情“部署”本身就不再是开发流程最后点一下按钮的动作而是要写进合约逻辑里的能力让合约去部署合约让任意用户通过一个入口创建任意合约。合约设计这个系列写到第9篇我打算把“部署任何合约”这个能力拆开讲透EVM底层是怎么部署的、CREATE和CREATE2有什么区别、通用部署器怎么写、构造参数怎么编码以及我实际踩过的那些坑。这篇文章适合正在写工厂类合约、做用户自助创建实例、或者想把多链部署流程自动化的Solidity开发者。1. 先想清楚什么场景下才需要“部署任何合约”1.1 三种部署路径从new到工厂到万能部署器最常见的写法是在合约里直接new一个合约比如new TokenVault(owner, name)。这种方式的优点是简单直接编译器帮你处理构造函数参数的编码部署逻辑清晰。但缺点是编译期就绑死了具体合约你没法部署一个运行期才决定代码内容的合约更没法让用户传入自己的字节码来创建实例。所以拿它做固定业务的工厂可以做“部署任何合约”就不行。稍微进化一点是预设工厂模式写一个Factory里面准备几种合约的构造分支通过枚举或者条件判断决定部署哪一个。这种方式比直接new灵活但每新增一种合约类型工厂合约就得跟着升级。如果你的业务是“今天支持Vault明天支持Token后天支持某种适配器”工厂永远在追新需求。第三个路径就是通用部署器也叫万能部署器。它的核心思想是把字节码本身作为参数传进来部署器不关心你要部署成什么合约只负责把字节码和构造参数拼好调用底层的create或create2指令然后把新地址返回给你。这才是真正意义上的“部署任何合约”。部署方式能部署什么灵活性典型场景new SomeContract(args)编译时写死的合约低简单工厂、固定业务实例预设分支的Factory工厂代码里预置的几种合约中限定几种类型的业务创建通用部署器传initCode任何EVM可部署的合约字节码高多链部署、用户自助创建、聚合协议1.2 通用部署器的典型使用场景我实际用下来通用部署器最值得做的场景有几个。一个是多链部署。一个协议往往要部署到十几条链上如果希望在每条链上都有一套部署器作为统一入口那么把部署器本身做成某个固定地址用户就只需要信任一个地址。配合CREATE2还能在正式部署之前就把未来合约的地址算出来提前写到其他协议里。第二个是用户自助创建。比如做一个个人代币工厂、个人保险柜、个人策略账户用户在前端点一下合约把一个字节码和参数传给通用部署器就能生成一个独立实例。这里通用部署器像一个“链上车间”用户只提供原料车间负责开工。第三个是协议聚合。很多聚合型协议需要动态创建外部系统的适配器或执行器这些适配器的代码可能是独立的第三方合约主合约没办法提前知道代码内容只能在运行期把字节码作为参数传进来。这种情况下通用部署器几乎是唯一干净的方案。需要提醒一个很关键的设计点用部署器部署合约时如果目标合约在构造函数里用了msg.sender来设置owner那部署出来的合约owner会变成部署器的地址而不是真正发起操作的用户。这个问题后面会详细讲但设计目标合约时就要刻意把控制权参数化。2. 读懂EVM的部署原理你才能写对部署器2.1 initCode到底是什么安装包和安装选项不管是用Remix点Deploy还是用Hardhat跑脚本链上发生的事情本质上是一样的发起一笔交易交易数据里携带一段叫initCode的字节EVM开辟一个新地址执行这段字节执行过程中返回的代码被存储到这个新地址上之后你就拥有了一个可以调用的合约。这段initCode并不是什么神秘的东西它就是合约的creationCode后面再拼上构造函数参数的ABI编码。可以理解成一份安装包creationCode是安装程序构造函数参数是你在安装时选择的选项而部署完成后存到链上的runtime code是安装完成后运行的正式程序。这里有个新手特别容易忽略的点EVM没有单独存放“构造函数参数”的字段参数就是直接追加在creationCode后面的那一段字节。编译器在编译new TokenVault(owner, name)时会自动把参数编码后拼上但如果你要写一个通用部署器收到的是一段原始字节码和一段原始参数必须自己完成这个拼接动作。拼接的时候要注意两块不定长的原始字节要使用bytes.concat(initCode, args)不能用abi.encode更不能随便用abi.encodePacked去拼动态类型的数据否则会导致参数边界丢失部署出来的合约要么直接回滚要么状态变成一堆乱码。这个坑我会在第5节展开说。2.2 create 和 create2 的差别与选择部署器底层要调用的指令有两个create和create2。它们都能根据initCode创建一个新合约但新地址的计算方式完全不同。create的地址公式是keccak256(rlp([sender, nonce]))[12:]sender是发起创建操作的合约地址nonce是它当前的非ce。这意味着地址不仅依赖部署者还依赖部署者的nonce而nonce会随着每次交易变化所以你很难提前预测未来创建出来的地址是什么。create2的地址公式是keccak256(0xff sender salt keccak256(initCode))[12:]多了一个salt参数。只要sender、salt、initCode三者不变创建出来的地址就永远一样和nonce完全无关。这就是“可预测地址”的核心原理。对比项CREATECREATE2地址依赖部署者地址和nonce部署者地址、salt、initCode是否可提前预测难以预测完全可预测同一个部署者重复调用每次地址不同相同salt下地址固定典型用途内部临时创建实例预先计算地址、Counterfactual部署、确定性实例我个人的选择经验是如果是合约内部临时创建一个辅助合约不关心地址长什么样用create就够了如果是要给用户创建独立实例或者需要在部署前就把地址告诉其他协议那必须用create2。CREATE2地址公式里哈希的是完整initCode也就是creationCode加上构造参数后的完整字节不是部署后的runtime code。这一点非常容易错很多人手动算地址对不上就是因为核心里哈希错了一段数据。2.3 部署失败的底层逻辑与gas走向写通用部署器之前你得先理解部署失败时发生了什么。EVM执行create或create2时如果initCode执行过程抛错、返回的代码超过合约大小上限、或者新合约构造函数拒绝接收转账指令会返回地址0而不是直接中断整个交易。地址0意味着“创建失败”你从失败本身拿不到任何具体错误信息。所以部署器里必须判断返回值我用的是require(deployed ! address(0), deploy failed)让调用者至少知道一个明确原因。但注意部署失败时已经消耗的gas不会退回所以失败的成本并不低尤其是initCode很大的时候。gas主要消耗在两个地方initCode执行本身的消耗以及存储代码的deposit费用。deposit大约是每字节200 gas但不同链可能调整以目标链为准。新网络还会实现对initCode长度的额外限制和计量所以不要想着搞一个几十KB的巨型合约塞进部署器很可能在initCode执行阶段就直接失败。这也解释了为什么通用部署器本身要尽量精简部署器自己的runtime code也要占用字节如果部署器太大再加上目标合约的体积很容易碰到合约大小上限。所以我把部署逻辑抽成一个library而不是全塞进部署器合约里。3. 手写一个通用部署器Lib 封装合约3.1 最小可行的DeployLib先给一个最小可用版本我把它写成library方便复用也能减少部署器自身的体积。// SPDX-License-Identifier: MIT pragma solidity ^0.8.20; library DeployLib { // 使用CREATE部署任意合约msg.value会作为新合约的初始资金 function deploy(bytes memory initCode, bytes memory args) internal returns (address deployed) { bytes memory fullCode args.length 0 ? bytes.concat(initCode, args) : initCode; assembly { deployed : create(callvalue(), add(fullCode, 0x20), mload(fullCode)) } require(deployed ! address(0), DeployLib: create failed); } // 使用CREATE2部署任意合约地址可预测 function deploy2(bytes memory initCode, bytes memory args, bytes32 salt) internal returns (address deployed) { bytes memory fullCode args.length 0 ? bytes.concat(initCode, args) : initCode; assembly { deployed : create2(callvalue(), add(fullCode, 0x20), mload(fullCode), salt) } require(deployed ! address(0), DeployLib: create2 failed); } // 按CREATE2公式提前推算部署出的地址 function predict( address creator, bytes32 salt, bytes memory initCode, bytes memory args ) internal pure returns (address predicted) { bytes memory fullCode args.length 0 ? bytes.concat(initCode, args) : initCode; predicted address( uint160( uint256( keccak256(abi.encodePacked(bytes1(0xff), creator, salt, keccak256(fullCode))) ) ) ); } }几个地方解释一下。bytes.concat(initCode, args)是Solidity 0.8.4之后提供的原始字节拼接函数语义明确专门用来拼接两个bytes类型不会做任何填充也不加长度前缀。如果你还在用老版本需要自己写内存拼接逻辑。内联汇编里的create(callvalue(), add(fullCode, 0x20), mload(fullCode))三个参数依次是传给新合约的ETH数量、initCode在内存中的起始位置、initCode的长度。add(fullCode, 0x20)是因为bytes类型在内存里前32字节是长度数据体从偏移32字节开始mload(fullCode)读出的就是字节长度。callvalue()拿到的是本次调用里调用者发送的ETH数量。我把这个值直接作为新合约的初始资金等于说调用者给部署器发多少value部署出来的合约就带着多少余额。这样设计可以避免部署器自己持有资金部署成功后部署器余额归零资金链非常干净。create2的四个参数顺序是value、内存位置、长度、salt写汇编时很容易把salt放到前面去这里注意一下。3.2 AnyDeployer封装部署、可预测、事件library是底层工具真正给用户调用的是封装合约。我把它命名为AnyDeployer暴露三个方法部署任意合约、用CREATE2部署任意合约、预测任意合约地址。contract AnyDeployer { event Deployed(address indexed deployed, bytes32 indexed salt, uint256 value); // 部署任意合约msg.value会作为新合约的初始资金 function deployAny(bytes calldata initCode, bytes calldata args) external payable returns (address deployed) { deployed DeployLib.deploy(initCode, args); emit Deployed(deployed, bytes32(0), msg.value); } // 用CREATE2部署任意合约salt由调用方控制地址可预测 function deployAny2( bytes calldata initCode, bytes calldata args, bytes32 salt ) external payable returns (address deployed) { deployed DeployLib.deploy2(initCode, args, salt); emit Deployed(deployed, salt, msg.value); } // 在部署之前先算一遍地址方便集成方预授权 function predictAny(bytes calldata initCode, bytes calldata args, bytes32 salt) external view returns (address predicted) { return DeployLib.predict(address(this), salt, initCode, args); } }deployAny和deployAny2都是payable调用者发送的ETH会先进入AnyDeployer的余额然后在执行create指令时被转给新合约。所以整个流程中AnyDeployer不会截留资金部署成功后它的余额恢复为0。事件的设计我刻意把salt和value一并记录这样前端在拿到交易回执后可以直接从事件里读出部署出的地址不用再做一次地址计算。predictAny用address(this)作为creator去计算地址因为真正执行部署的合约就是AnyDeployer自己。如果你在某条链上部署了AnyDeployer那么预测地址的creator参数只能是它的地址不能填用户的EOA地址否则永远对不上。3.3 这个设计里的取舍和注意点为什么把部署逻辑放在library里而不是直接写在AnyDeployer里主要是为了控制AnyDeployer的runtime code体积。通用部署器的价值在于“什么都能部署”但目标合约本身的体积是不可控的有些大型协议合约已经逼近24576字节的上限。如果部署器自己就很大叠加目标合约会更容易碰到上限所以能省则省。另一个取舍是透传msg.value而不是设计一个手动传value参数。因为手动传参数意味着调用者要先给部署器充值部署器就要有receive函数还要有人负责把多余的钱取出来徒增复杂度。现在这个设计调用者发多少value新合约就收到多少value逻辑上最直白。还有版本和兼容问题。我用的bytes.concat要求Solidity 0.8.4以上如果你要部署到对编译器版本比较保守的老链可以降到0.8.7这类版本也能用。但如果你的目标链对最新编译器有兼容问题就得注意替换相关语法。这里还要再强调一次owner问题如果目标合约构造函数里写了owner msg.sender那么通过AnyDeployer部署出来的合约owner就是AnyDeployer的地址永远不可能是用户。要解决这个问题只能在目标合约的设计上把owner做成显式的构造参数由调用者传进去。4. 实操演练把它部署一个TokenVault到链上4.1 目标合约与creationCode获取为了演示我写了一个简单的TokenVault构造函数接收owner地址和一个名称字符串支持充值、提现。注意构造函数是payable的这样部署时可以直接带一笔初始资金。// SPDX-License-Identifier: MIT pragma solidity ^0.8.20; contract TokenVault { address public immutable owner; string public name; event MoneyIn(address indexed from, uint256 amount); constructor(address _owner, string memory _name) payable { owner _owner; name _name; } function deposit() external payable { emit MoneyIn(msg.sender, msg.value); } function withdrawAll(address to) external { require(msg.sender owner, not owner); (bool ok, ) to.call{value: address(this).balance}(); require(ok, withdraw failed); } }部署器需要的是TokenVault的creationCode也就是不含构造函数参数的原始字节码。在Hardhat里可以这样拿到const artifact await hre.artifacts.readArtifact(TokenVault); const initCode artifact.bytecode;如果你在Remix里手动操作编译后的Bytecode里那个object字段就是creationCode带不带0x都行ethers会帮你处理。这里最忌讳的是拿deployedBytecode去当initCode那是合约部署完成后的runtime code不是安装包两者完全不是一回事。4.2 Hardhat调用部署器的完整脚本完整的调用流程分四步部署AnyDeployer、编码TokenVault的构造参数、用predictAny先算地址、用deployAny2实际部署。下面是一个基于Hardhat和ethers v6的脚本。const { ethers } require(hardhat); async function main() { // 1. 部署通用部署器 const AnyDeployer await ethers.getContractFactory(AnyDeployer); const anyDeployer await AnyDeployer.deploy(); await anyDeployer.waitForDeployment(); const deployerAddr await anyDeployer.getAddress(); console.log(AnyDeployer:, deployerAddr); // 2. 读取目标合约的creationCode const artifact await hre.artifacts.readArtifact(TokenVault); const initCode artifact.bytecode; // 3. 编码构造函数参数owner name const abiCoder ethers.AbiCoder.defaultAbiCoder(); const owner 0xYourAddress; const args abiCoder.encode( [address, string], [owner, My First Vault] ); // 4. 用CREATE2预测地址 const salt ethers.id(demo-vault-001); const predicted await anyDeployer.predictAny(initCode, args, salt); console.log(predicted:, predicted); // 5. 实际部署带1 ETH作为新合约的初始资金 const tx await anyDeployer.deployAny2(initCode, args, salt, { value: ethers.parseEther(1), }); await tx.wait(); console.log(deployed:, predicted); // 6. 检查合约状态 const vault await ethers.getContractAt(TokenVault, predicted); console.log(owner:, await vault.owner()); console.log(name:, await vault.name()); console.log(balance:, ethers.formatEther(await ethers.provider.getBalance(predicted))); } main().catch(console.error);脚本里第4步的predictAny调用是整个流程的保险栓。先用合约自己算一遍地址如果这个地址和最终实际部署地址不一致说明initCode、args或者salt至少有一个地方传错了这时应该先排查数据而不是继续往下走。salt我用ethers.id(demo-vault-001)生成它会变成一个bytes32值。实际业务里可以用用户地址加序号来派生salt保证每个用户拿到的实例地址互不相同。你也可以直接传ethers.ZeroHash但同一个salt只能部署一次重复部署会失败因为目标地址已经有代码了。调用deployAny2时如果目标构造函数不接受ETH就不要传value否则部署会回滚。TokenVault构造函数是payable的所以传1 ETH没问题这1 ETH会成为新合约的初始余额。4.3 部署后的验证与交互脚本最后已经把新合约挂到了predicted地址上你可以直接查owner、name和余额。如果owner打印出来是你的EOA地址说明构造函数参数编码正确部署器也没有在中间截胡控制权。这时候再往合约里转一笔ETH调用一下deposit会触发MoneyIn事件验证逻辑正常。然后调用withdrawAll把余额转走。这样一趟流程下来TokenVault从出生到使用都是完整的。一个小细节部署后如果再次调用predictAny返回的地址还是同一个但此时该地址已经有代码了。再调用deployAny2就会失败因为CREATE2不允许覆盖已有代码的地址。如果你希望同一个salt能反复部署新实例需要在salt里加入足够多的随机性或者自增序号这个在工厂类业务里尤其重要。5. 踩坑记录部署器最常见的6个问题5.1 构造参数编码翻车string参数一传就炸第一个高频坑是构造参数编码错误。症状是部署回滚或者部署成功了但字符串状态变成乱码。最常见的原因是用abi.encodePacked去编码构造参数。abi.encodePacked对于两个动态类型数据之间没有边界标记比如abi.encodePacked(owner, MyVault)它会把地址和字符串直接粘在一起解码时完全不知道从哪里切开。正确做法是用abi.encode生成标准ABI编码每个参数按32字节对齐解码器才知道边界。另外注意不能把abi.encodeWithSignature(constructor(address,string), ...)的结果当args用那个结果带了函数选择器而构造函数的参数编码不需要选择器。我一开始没意识到这一点部署出来的合约总是莫名其妙回滚排查了半天才发现是args里多带了一段脏数据。5.2 CREATE2地址永远对不上按这个顺序查预测地址和实际部署地址不一致这是第二个高频坑。我总结了排查顺序。第一确认creator是AnyDeployer的地址不是用户EOA。第二确认salt完全一致bytes32的一个字节都不能差。第三确认initCode用的是creationCode不是deployedBytecode。第四确认args用的是abi.encode编码后的结果没多带也没少带。第五确认公式里的哈希对象是完整initCode不是runtime code。还有一个土办法在脚本里打印keccak256(fullCode)的哈希值然后在predictAny的返回值上反推两边对不上就逐个字段排查。用合约自身暴露的predictAny去算地址比自己在脚本里复现CREATE2公式要省心得多因为合约的公式不会写错。5.3 部署成功但owner不对msg.sender陷阱第三个坑是合约部署成功了看起来一切正常但owner变成了AnyDeployer地址。根因我在前面反复强调目标合约构造函数里用了msg.sender来指定owner。通过AnyDeployer部署时msg.sender就是AnyDeployer不是调用者。解决办法是在目标合约里把owner做成显式构造参数由调用者在编码args时传进去。如果目标合约不是你写的那就得看它有没有后续的transferOwnership方法部署后手动转移。这个坑其实暴露了一个更普遍的设计原则任何要被工厂或部署器创建的合约都应该把“谁是这个实例的控制者”作为构造参数而不是隐式依赖msg.sender。5.4 合约太大部署回滚EIP-170上限第四个坑是部署巨型合约失败。症状是create返回0交易回滚gas消耗很高但看不到具体错误。EIP-170规定合约runtime code最大24576字节超过就部署失败。如果你的业务合约已经很接近这个上限再套一层部署器逻辑叠加起来就非常危险。解决思路有几种把合约拆分成多个小合约组合用代理模式把核心逻辑放到一个实现合约各实例只存储状态或者如果只是同模板多实例直接上EIP-1167克隆。另外新版网络对initCode的长度也有了限制和额外计量所以不仅在runtime端在initCode端也可能先爆掉。我的习惯是部署前先量一下目标合约的字节码长度如果接近上限尽早规划拆分方案别等到部署失败再改。5.5 进阶推荐用Clone代理把gas降到十分之一如果你要创建的是同一个模板的很多实例而每个实例的初始化数据又比较简单那强烈建议用EIP-1167最小代理替代完整部署。思路是先部署一个implementation合约之后每次创建实例时不再复制整个合约代码只用大约60字节的代理代码指向implementation。代理合约把所有调用通过delegatecall转给implementation状态存在代理实例自己身上。成本能降一个数量级部署时间也快很多。Solidity里用CREATE2部署clone的代码大致是这样function deployClone(address implementation, bytes32 salt) internal returns (address instance) { bytes memory code abi.encodePacked( hex3d602d80600a3d3981f3363d3d373d3d3d363d73, implementation, hex5af43d82803e903d91602b57fd5bf3 ); assembly { instance : create2(0, add(code, 0x20), mload(code), salt) } require(instance ! address(0), clone failed); }要注意克隆模式里实例自身的状态变量和implementation的storage布局必须完全兼容升级implementation时还要考虑已有实例的行为变化。克隆不是万能药但对于“同模板多实例”的场景效果立竿见影。5.6 gas估算和调试技巧最后分享几个调试习惯。用ethers调用通用部署器时estimateGas有时候会不准确因为交易data里包含了完整字节码钱包和provider对合约内动态部署的gas估算本来就偏保守。我的做法是先预测地址再给一个保守的gasLimit比如直接在交易参数里写gasLimit: 5000000省得前台报错。部署失败又查不出原因时优先在本地做hardhat fork把主网状态拉下来再用console.log在目标合约的构造函数里插桩本地跑一遍看哪一步revert。不要在主网上反复试错既费gas又费时间。还有一个我坚持的习惯所有使用部署器的地方都保留predict接口部署前链上算一遍地址前端再算一遍地址两面对不上就直接在交互层拦住用户。这个前置检查看起来多此一举但真的能挡住一大批编码问题。用通用部署器大半年我的体会是“部署任何合约”本身只是一个框架能力真正决定上限的是合约设计控制权参数化、地址可预测、runtime code尽量小。如果你正在做多链部署或者工厂类协议建议先把这几个问题想清楚再动手。另外一个经验是我会把predictAny方法保留在所有实际项目里任何一次创建操作都先让用户看到即将生成的地址确认无误再上链这个习惯帮我省下了无数次排查事故的时间。
阅读完成 · 觉得有帮助？
