以太坊智能合约地址派生方式：EOA、CREATE 和 CREATE2

mutourend2025-08-24 8:50

1. 引言

在以太坊上，智能合约可以通过以下三种方式之一进行部署：

  • 1）由外部账户（Externally Owned Account, EOA）发起交易，其中 to 字段设为 null，而 data 字段包含合约的初始化代码。
  • 2）智能合约调用 CREATE 操作码。
  • 3）智能合约调用 CREATE2 操作码。

本文将探讨如何预测在这三种情况下即将创建的合约地址。

2. 预测由 EOA 或 CREATE 部署的智能合约地址

对于由 EOA 或 CREATE 操作码（非 CREATE2）部署的合约，其地址是通过对 RLP 编码 的 发送者地址和 nonce 进行 Keccak-256 哈希计算得到的。合约地址取该哈希的最后 20 字节（160 位）。

复制代码 
address = keccak256(RLP([deployer, nonce]))[:20]

如上式所示，这种地址计算方式只依赖于 部署者的地址 和 其 nonce。它不会考虑合约的字节码、构造函数参数或任何其他因素。

2.1 递归长度前缀编码（Recursive Length Prefix, RLP）

在高层次上，RLP 会将要发送的数据项拼接起来。

除去范围 [0x00, 0x7f] 内的单字节，每个数据项都会有一个或多个前缀字节，指示该项是字符串还是列表，以及其负载的长度。详情可参看RLP文档 。

为了理解 RLP 编码在合约地址预测中的应用，来看一个实际示例。

2.2 RLPDemo 示例

在下面的 RLPDemo 合约中，predictContractAddress 函数实现了与 CREATE 操作码相同的地址派生逻辑：

  • 通过对 发送者地址和 nonce 进行 RLP 编码，计算出预期的部署地址。
solidity 复制代码 
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

contract RLPDemo {  
    // 预测给定地址会部署的合约地址
    function predictContractAddress(  
        address deployer,  
        uint nonce  
    ) public pure returns (address) {  
        // 实现与 CREATE 操作码相同的地址推导逻辑

        // CREATE 地址推导规则：
        // keccak256(rlp([sender_address, sender_nonce]))
        bytes memory rlpEncoded;

        // RLP 编码规则：
        // - nonce = 0 时，RLP 编码为 [0x80]（空字节串）
        // - nonce = 1 到 127 时，RLP 编码就是该字节本身 (0x01 到 0x7f)
        // - nonce = 128 到 255 时，RLP 编码为 [0x81, nonce]
        //   其中 0x81 表示后续字节是单字节长度前缀

        // 注意：完整的 RLP 规范支持任意长度整数的编码，
        // 但此函数只支持 nonce ≤ 255。

        if (nonce == 0) {  
            // nonce = 0
            rlpEncoded = abi.encodePacked(  
                bytes1(0xd6), // 某list的RLP前缀
                bytes1(0x94), // 某20 字节地址的RLP前缀
                deployer,     // 部署者地址（20 字节）
                bytes1(0x80)  // nonce = 0 的 RLP 编码------即为0x80
            );  
        } else if (nonce < 128) {  
            // nonce = 1--127
            rlpEncoded = abi.encodePacked(  
                bytes1(0xd6), // 某list的RLP前缀
                bytes1(0x94), // 某20 字节地址的RLP前缀
                deployer,     // 部署者地址（20 字节）
                uint8(nonce)  // nonce 单字节
            );  
        } else if (nonce < 256) {  
            // nonce = 128--255
            rlpEncoded = abi.encodePacked(  
                bytes1(0xd7), // 某list的RLP前缀（更长一字节）
                bytes1(0x94), // 某20 字节地址的RLP前缀
                deployer,     // 部署者地址（20 字节）
                bytes1(0x81), // 某单字节的RLP前缀
                uint8(nonce)  // nonce 单字节
            );  
        } else {  
            revert("Nonce too large for this demo");  
        }

        bytes32 hash = keccak256(rlpEncoded);  
        return address(uint160(uint256(hash)));  
    }  
}

为了验证 predictContractAddress 是否能正确运行，在此使用了 EOA 地址 0x17F6AD8Ef982297579C203069C1DbfFE4348c372 部署了 RLPDemo（即上面的合约）。

结果得到的合约地址是：

复制代码 
0xE2DFC07f329041a05f5257f27CE01e4329FC64Ef

上面描述的部署结果展示在下图右侧：

如图左侧所示，调用 predictContractAddress，输入部署者地址 0x17F6AD8Ef982297579C203069C1DbfFE4348c372 和 nonce = 0，成功预测了此前部署的合约地址：

复制代码 
0xE2DFC07f329041a05f5257f27CE01e4329FC64Ef

接下来，将探讨 nonce 在外部账户（EOA）与合约账户 中的不同解释方式。

2.3 账户部署过程中的 Nonce 序列

先来理解一下以太坊中 nonce 的定义。根据 以太坊黄皮书，账户的 nonce 定义为：

nonce: 一个标量值，等于从该地址发送的交易数量，或者在与代码相关联的账户情况下，该账户创建的合约数量。对于状态中的地址 a a a 的账户，可以形式化表示为 σ [ a ] n \sigma[a]_n σ[a]n。

从这个定义可以看出，nonce 是赋予发起交易或部署合约的地址的一个计数值。由于 EOA（Externally Owned Account，外部账户）可以直接发起和签名交易，nonce 计数可以反映 ETH/代币转账、合约调用以及合约部署等操作。需要注意的是，即使交易回滚（revert），nonce 仍然会递增。因为被回滚的交易仍然被打包进区块中，这依旧计入 nonce 的增加。

相比之下，智能合约不能自主发起交易；它们只能在被 EOA 或其他合约调用时执行。因此，合约账户的 nonce 仅反映该合约发起的合约创建操作。

注意：内部调用（internal call）、消息调用（message call）、事件以及交易内部发生的其他操作都不会增加账户的 nonce。

接下来看看 nonce 如何初始化，并如何用于预测 EOA 和合约账户的地址。

  • 新建的 EOA 的 nonce 初始值为 0，每次交易递增 1。
    如果新建的 EOA 用来部署合约，0 将作为 nonce 来预测该合约的地址。
    但如果该账户已经进行过转账或部署操作，那么其 nonce 将大于 0。
  • 合约账户 的 nonce 在创建时初始化为 1，这是 EIP-161 的规定。
    当合约通过 CREATE 或 CREATE2 创建其他合约时，其 nonce 会递增 1。

如，假设刚刚部署了合约 A。

  • 部署完成后，合约 A 的 nonce 被设置为 1。如果合约 A 随后创建另一个合约（如合约 B），那么该创建操作将使用 nonce = 1 来计算合约 B 的地址。
    • 一旦合约 B 创建完成，合约 A 的 nonce 递增为 2。
    • 如果合约 A 想再创建另一个合约（如合约 C），它将使用 nonce = 2。合约 C 创建完成后，合约 A 的 nonce 变为 3，以此类推。
    • 合约 B 和合约 C 作为新合约，它们的初始 nonce 都是 1。

2.4 如何获取账户的 Nonce

EVM 没有直接获取账户 nonce 的操作码。但可以使用 eth_getTransactionCount RPC 方法来获取指定账户的 nonce。

这个方法返回指定地址的 交易数量，对应账户的 nonce。

  • 对于 EOA，这包括 ETH/代币转账、合约调用和合约部署。
  • 对于 智能合约 ，eth_getTransactionCount 只反映该合约地址创建的合约数量。

下面的图片展示了：只有合约部署才会增加合约地址的 eth_getTransactionCount nonce 。

以下是一个使用 eth_getTransactionCount 方法获取 nonce 的 JavaScript 示例：

js 复制代码 
// NECESSARY IMPORTS
import { createPublicClient, http } from 'viem';
import { mainnet } from 'viem/chains';

// CREATE A PUBLIC CLIENT
const publicClient = createPublicClient({
  chain: mainnet,
  transport: http()
});

// GET TRANSACTION COUNT (NONCE)
const transactionCount = await publicClient.getTransactionCount({
  address: '0xYourContractAddress'
});
console.log(transactionCount);

在测试中，可以使用 Foundry 的 vm.getNonce cheatcode。

2.4.1 Foundry 的 getNonce 方法

在 Foundry 中，vm.getNonce cheatcode 允许获取给定账户或钱包在 EVM 上的当前 nonce。

在 Foundry 环境中可用的 getNonce 方法如下：

solidity 复制代码 
// 返回指定账户的 nonce
function getNonce(address account) external returns (uint64);

在下面的 test_eoaAndContractNonces() 示例中，验证了：

  • EOA（userEOA）的 nonce 从 0 开始；
  • 新部署的合约（SomeContract）的 nonce 从 1 开始，符合预期。
solidity 复制代码 
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "forge-std/Test.sol";

contract SomeContract {
    // 如果需要，可以在这里编写逻辑
}

contract CreateAddrTest is Test {
    address userEOA = address(0xA11CEB0B);
    SomeContract public newContract;

    function setUp() public {
        // 给 EOA 账户分配 10 ether
        vm.deal(userEOA, 10 ether);

        // 部署 SomeContract（它会在构造函数中部署 Dummy 合约）
        newContract = new SomeContract();
    }

    function test_eoaAndContractNonces() public view {
        // 1. EOA 的 nonce 初始应为 0
        uint256 eoaNonce = vm.getNonce(userEOA);
        console.log("EOA nonce:", eoaNonce);
        assertEq(eoaNonce, 0);

        // 2. 新部署合约的 nonce 初始应为 1
        uint256 contractNonce = vm.getNonce(address(newContract));
        console.log("SomeContract contract nonce:", contractNonce);
        assertEq(contractNonce, 1);
    }
}

终端输出结果：

2.5 使用 EOA 部署合约时预测合约地址（基于 LibRLP）

https://github.com/Vectorized/solady 提供了一个实用工具 LibRLP，其中包含一个 computeAddress 函数，该函数使用其内部的 RLP 编码实现来计算地址。这个辅助函数抽象掉了编码的细节，直接返回由 EOA 或 CREATE 部署生成的合约地址。

solidity 复制代码 
function computeAddress(address deployer, uint256 nonce)  
        internal  
        pure  
        returns (address deployed)  
    {  
        /// @solidity memory-safe-assembly  
        assembly {  
            for {} 1 {} {  
                // 整数 0 会被视为一个空的字节字符串，
                // 因此它只有一个长度前缀 0x80，
                // 计算方式为 `0x80 + 0`。

                // 在 [0x00, 0x7f] 范围内的一字节整数
                // 其自身值即作为长度前缀，
                // 并不会再有额外的 `0x80 + length` 前缀。
                if iszero(gt(nonce, 0x7f)) {  
                    mstore(0x00, deployer)  
                    // 使用 `mstore8` 而不是 `or`，可以自然清除
                    // `deployer` 的高位脏比特。  
                    mstore8(0x0b, 0x94)  
                    mstore8(0x0a, 0xd6)  
                    // `shl 7` 等价于乘以 0x80。  
                    mstore8(0x20, or(shl(7, iszero(nonce)), nonce))  
                    deployed := keccak256(0x0a, 0x17)  
                    break  
                }  
                let i := 8  
                // 使用循环泛化所有情况，保持字节码尽量小。  
                for {} shr(i, nonce) { i := add(i, 8) } {}  
                // `shr 3` 等价于除以 8。  
                i := shr(3, i)  
                // 逆序存储到 slot，以正确覆盖值。  
                mstore(i, nonce)  
                mstore(0x00, shl(8, deployer))  
                mstore8(0x1f, add(0x80, i))  
                mstore8(0x0a, 0x94)  
                mstore8(0x09, add(0xd6, i))  
                deployed := keccak256(0x09, add(0x17, i))  
                break  
            }  
        }  
    }

为了理解其实际效果，将部署下面的 CreateAddressPredictor 合约。然后调用 addrWithLibRLP 来测试计算结果是否与实际部署的 CreateAddressPredictor 地址一致。

solidity 复制代码 
// SPDX-License-Identifier: MIT  
pragma solidity ^0.8.4;

// 导入 LibRLP，其中包含上面展示的 computeAddress 函数。
import {LibRLP} from "contracts/LibRLP.sol";

contract CreateAddressPredictor {  
    // 合约内部调用 Solady 的地址计算逻辑，
    // 并通过 addrWithLibRLP 暴露出来。  
    function addrWithLibRLP(  
        address _deployer,  
        uint256 _nonce  
    ) public pure returns (address deployed) {  
        return LibRLP.computeAddress(_deployer, _nonce);  
    }  
}

使用 EOA 地址 0xAb8483F64d9C6d1EcF9b849Ae677dD3315835cb2，在 Remix 上部署了 CreateAddressPredictor，部署地址为：

复制代码 
0xa131AD247055FD2e2aA8b156A11bdEc81b9eAD95

这是终端的结果：

当调用 addrWithLibRLP，传入与部署 CreateAddressPredictor 相同的 EOA 和 nonce = 0 时，返回的地址与实际部署地址一致，符合预期。

如下图所示，实际部署的合约地址与预测出的地址完全一致：

注意：

  • 在这个例子中，如果 nonce 设置为非零值，解码输出将返回错误的地址，因为以上是用一个新建的 EOA 账户做的测试。

2.6 预测由合约部署的合约地址

如前所述，无论部署者是 EOA 还是合约，合约地址的推导方式都是相同的。只需要正确设置部署者地址和 nonce。

在下面的测试中，Deployer 合约演示了如何通过 computeAddress 方法计算出的地址与合约实际部署的地址相对应。

solidity 复制代码 
// SPDX-License-Identifier: MIT  
pragma solidity ^0.8.0;  
import "contracts/LibRLP.sol";

contract C {}

contract Deployer {  
    // 注意：nonce 并不会存储在链上 ------ 这里只是用来做记录  
    uint256 public contractNonce = 1;

    function deploy() public returns (address c) {  
        address predicted = predictAddress(address(this), contractNonce);  
        c = address(new C());  
        require(c == predicted, "Address mismatch");  
        contractNonce += 1;

        return c;  
    }

    function predictAddress(  
        address _deployer,  
        uint256 _nonce  
    ) public pure returns (address deployed) {  
        return LibRLP.computeAddress(_deployer, _nonce);  
    }  
}

C 合约由 Deployer 合约使用 new 关键字部署（底层调用的是 CREATE opcode）。

在上述例子中，使用 contractNonce 来存储部署次数，方便追踪。因为如果要从智能合约中直接发起 RPC 调用则需要预言机支持。

由于 contractNonce 初始化为 1，并且在每次部署后递增，所以预测的地址总是与实际部署地址一致。因此 deploy() 调用不会回滚。

换句话说，用 nonce 来追踪部署次数，只是为了方便而已。

solidity 复制代码 
require(c == predicted, "Address mismatch");  
// 如果条件不满足，deploy() 调用会回滚

假设在第一次部署成功后，再次部署第二个合约。在此之前，contractNonce 将被递增为 2，然后才会发生第二次部署。

这是第二次部署时 deploy() 调用的结果：

下面的图片显示，实际部署的合约地址与 predictAddress 调用返回的地址（内部调用了 LibRLP.computeAddress）完全一致。

3. 如何使用 CREATE2 预测合约地址

Create2 在 EIP-1014 中被引入。

当使用 CREATE2 指令部署合约时，其地址取决于三个组成部分：

公式如下：

text 复制代码 
Create_contract_address = keccak256(0xff ++ deployer ++ salt ++ keccak256(init_code))

利用这个关系，可以在部署前预计算合约的地址，如下方 getAddress 函数所示：

solidity 复制代码 
function getAddress(  
    bytes memory createCode,  
    uint _salt  
) public view returns (address) {  
    bytes32 hash = keccak256(  
        abi.encodePacked(  
            bytes1(0xff),  
            address(this),  
            _salt,  
            keccak256(createCode)  
        )  
    );  
    return address(uint160(uint(hash)));  
}

其中：

  • 0xff 是一个常量，用来区分 CREATE2 和 CREATE。
  • salt 是用户定义的值（32 字节），用来确保唯一性。
  • keccak256(createCode) 是合约初始化代码的哈希值。

3.1 为什么 CREATE2 要在前面加上 1 个 0xff 字节

在 keccak256 输入中，0xff 是区分字节，用于确保 CREATE 和 CREATE2 生成的地址不会发生冲突。

回忆一下，CREATE 使用 RLP 对两个元素（[deployer, nonce]）进行编码来计算地址。背景信息：

  • 部署者的地址始终是 20 字节；
  • nonce 的字节长度取决于其值（实际应用中范围是 0--8 字节，理论上不受限）。

由于 RLP 列表前缀取决于 payload 的总长度，当 nonce 变大时，payload 的长度可能增加，从而改变前缀。

如，如果 payload 长度 ≤ 55 字节，前缀范围是：

text 复制代码 
0xc0 + payload_length

如果 nonce 大到其 RLP 编码超过 34 字节，那么整个 [deployer, nonce] payload 就会超过 55 字节阈值，此时列表前缀会落在范围 [0xf8, 0xff]。不过这种情况在现实中不会发生，因为 34 字节的 nonce 意味着超过 170 亿笔交易 ------ 远超出实际可能。

此外，EIP-2681 规定 nonce 的硬性上限为 8 字节（64 位），即任何 nonce ≥ 2^64-1 的交易无效。因此，rlp.encode([deployer, nonce]) 的前缀始终落在 [0xc0, 0xf7] 范围内。

如：

text 复制代码 
// 在此，0xd6 表示一个长度为 22 字节的 RLP 列表
rlp.encode([deployer, nonce]) = 0xd6 94 <20-byte deployer> <nonce>

因此，如果 CREATE2 不在前面加上 0xff，而是简单地将 deployer ++ salt ++ keccak256(init_code) 拼接后哈希，那么理论上（虽然几乎不可能），可能会存在某些取值，使得结果字节串的前缀与某个 [deployer, nonce] 的 RLP 编码一致。这样的话，两个域就无法做到严格区分。

通过在最前面加上一个 0xff 字节，CREATE2 可以确保哈希输入始终以 0xff 开头，而这个值在真实账户的 RLP 编码中永远不会出现。这样就能在计算哈希前实现 完全的域隔离。

3.2 CREATE2 预计算示例

接下来看一个例子：使用 getAddress 方法从合约 A 计算新地址。注意，这个合约没有构造函数。

solidity 复制代码 
contract A {  
    address public owner;

    function getBalance() public view returns (uint256) {  
        return address(this).balance;  
    }  
}

在下面的 DeployNewAddr 合约中，getAddress 函数接收合约 A 的创建字节码和一个 salt，并计算出 CREATE2 部署合约时的地址。在这里，计算过程中使用的是 DeployNewAddr 的地址（即 address(this)）。因此，最终的合约地址取决于：

  • DeployNewAddr 的地址，
  • 提供的 salt，
  • 以及创建（init）字节码 的哈希。
solidity 复制代码 
contract DeployNewAddr {  
    function getAddress(  
        bytes memory createCode,  
        uint _salt  
    ) public view returns (address) {  
        bytes32 hash = keccak256(  
            abi.encodePacked(  
                bytes1(0xff),  
                address(this),  
                _salt,  
                keccak256(createCode)  
            )  
        );  
        return address(uint160(uint(hash)));  
    }

    function getContractABytecode() public pure returns (bytes memory) {  
        bytes memory bytecode = type(A).creationCode;

        return abi.encodePacked(bytecode);  
    }  
}

注意：

  • getAddress() 只有在真正执行部署的合约是 DeployNewAddr 本身时，才会返回正确的 CREATE2 地址。
  • 如果是其它合约用相同的字节码和 salt 部署，那么结果地址会不同，因为计算中用到的 address(this)（部署者地址）不一致。

因此，当在真实部署环境之外使用 getAddress() 时，必须确保计算中使用的部署者地址与实际执行部署的合约一致。

接下来，考虑 合约 A 有构造函数并带参数的情况。

3.3 在 getContractABytecode 方法中处理带构造函数参数的合约

当合约被部署时（无论是由 EOA 还是合约部署），EVM 会执行合约的 创建代码 。

这部分创建代码由 creationCode（已编译的初始化字节码） 与 ABI 编码后的构造函数参数 拼接而成。

因此，这种行为并不是 CREATE2 所特有的。

回顾上一节，选择通过一个辅助函数 getContractABytecode 来获取 getAddress 的 createCode 参数。

因此，对于带有构造函数参数的合约 A，该辅助函数需要在合约的 创建字节码后拼接参数，并且要保证参数的编码格式正确。

下面是一个修改后的合约 A，它有一个构造函数参数：

solidity 复制代码 
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract A {
    address public owner;

    constructor(address _owner) payable {
        owner = _owner;
    }

    function getBalance() public view returns (uint256) {
        return address(this).balance;
    }
}

如果合约 A 包含如上所示的构造函数参数，那么 getContractABytecode 函数会将 _owner 参数的 ABI 编码追加到字节码中，即：

复制代码 
abi.encodePacked(bytecode, abi.encode(_owner))

如果合约 A 有多个构造函数参数，如下所示：

solidity 复制代码 
contract A {
    address public owner;
    address public artMaster;

    constructor(address _owner, address _artMaster) payable {
        owner = _owner;
        artMaster = _artMaster;
    }

    /***********other logic***********/
}

在这种情况下，部署字节码必须包含所有参数，并且按正确顺序编码：

复制代码 
abi.encodePacked(bytecode, abi.encode(arg1, arg2, ...))

因此，对于有 _owner 和 _artMaster 两个构造函数参数的合约 A，getContractABytecode 函数如下所示：

solidity 复制代码 
function getContractAInitByteCode(
    address _owner,
    address _artMaster
) public pure returns (bytes memory) {
    bytes memory bytecode = type(A).creationCode;

    return abi.encodePacked(bytecode, abi.encode(_owner, _artMaster));
}

在测试上面 DeployNewAddr 合约中的 getAddress 方法之前，先来看另一种 CREATE2 的部署方式。

  • 这种方式 不需要手动传递创建字节码 ，而是通过 Solidity 的 原生合约实例化语法 隐式生成。

3.4 不手动传递创建字节码的 CREATE2 合约部署

这种 CREATE2 方法使用 Solidity 内置的 new 关键字，结合 salt 参数来部署合约并返回其地址。

在这种方式下，编译器会自动处理创建字节码的生成和构造函数参数的编码，因此无需手动传递或拼接。

下面的 DeployNewAddr1 演示了这种方式：

solidity 复制代码 
contract DeployNewAddr1 {
    // 返回新部署合约的地址
    // DeployNewAddr1 展示了一个没有构造函数参数的简单部署 (A())。
    function deploy(uint _salt) external returns (address x) {
        A Create2NewAddr = new A{salt: bytes32(_salt)};
        return address(Create2NewAddr);
    }
}

上面代码中的 deploy 函数演示了 当合约 A 没有构造函数参数时的部署方法。

下面的 DeployNewAddr2 和 DeployNewAddr3 展示了 当合约 A 有一个或两个构造函数参数时的部署方式：

solidity 复制代码 
contract DeployNewAddr2 {
    // 包含一个构造函数参数 _owner
    // 该参数会传入合约 A 的构造函数
    // Solidity 会自动编码构造函数参数并将其拼接到创建字节码
    function deploy(uint _salt, address _owner) external returns (address x) {
        A Create2NewAddr = new A{salt: bytes32(_salt)}(_owner);

        return address(Create2NewAddr);
    }
}
solidity 复制代码 
contract DeployNewAddr3 {
    // 包含两个构造函数参数（msg.sender 和 _artMaster）
    // 与 DeployNewAddr2 一样，这些参数会被编码并包含在创建字节码中
    function deploy(
        uint _salt,
        address _owner,
        address _artMaster
    ) external returns (address x) {
        A Create2NewAddr = new A{salt: bytes32(_salt)}(_owner, _artMaster);

        return address(Create2NewAddr);
    }
}

接下来，运行带有一个构造函数参数的代码，看看 DeployNewAddr2 中的 deploy 是否会返回与 DeployNewAddr 合约中 getAddress 相同的预测地址。

这两个方法都使用 salt = 29，其中 getAddress 方法的 bytecode 来自 getContractABytecode。

调用两个方法得到的结果如下所示：

从上图可以看到，deploy 函数返回的地址与 getAddress 函数返回的地址 完全一致。

4. 如何部署两个相互引用地址（A 和 B）的智能合约，并且地址不可变

接下来将举例展示地址预测如何减少合约部署的成本。

假设想要部署两个智能合约（A 和 B），并且每个合约都需要引用对方的地址 。此外，它们的地址必须永不改变（不可变）。

这种设置引入了几个需要解决的挑战：

  • 先部署 A 时，A 无法引用尚未存在的 B
  • 先部署 B 时，会出现相反的问题 ------ B 无法引用未部署的 A
  • 部署完成后，地址必须是不可变的；不能使用 setter 函数或外部更新

一种解决办法是：

  • 通过工厂合约的地址预计算 A 和 B 的地址。
  • 然后用预计算得到的 B 的地址作为构造函数参数部署 A，
  • 同样用 A 的预计算地址来部署 B。

尽管这种方法在技术上是正确的，但它存在一些权衡：

  • 工厂合约本身需要部署并存储在链上，从而增加整体字节码占用
  • 部署工厂合约以及调用其逻辑来部署目标合约，都会消耗额外的 gas

为了避免这些开销，可以使用普通的合约部署方式，并利用本文讨论的技术来预测地址。

4.1 使用 Foundry 脚本（RLP 方法）预计算合约地址

以下步骤展示了如何使用 foundry 脚本 来完成：

  • 会打印工厂账户（一个 EOA）的地址，获取它的当前 nonce，预计算合约地址（基于 EOA 的 nonce），并在部署时让它们相互引用。

具体分为3步：

  • 1）步骤 1：编写脚本打印工厂（部署者）地址
  • 2）步骤 2：计算合约 A 和 B 的地址
  • 3）步骤 3: 使用对应的构造函数参数（即预计算的地址）部署合约

4.1.1 步骤 1：编写脚本打印工厂（部署者）地址

solidity 复制代码 
// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.13;

import {Script, console} from "forge-std/Script.sol";
import {A, B} from "../src/DeployAddr.sol";

contract DeployAddrScript is Script {
    A public a;

    function run() public {
        uint256 pk = vm.envUint("PRIV_KEY");
        address dep = vm.addr(pk);
        // ⚠️ WARNING: 使用 vm.envUint 时，私钥会以明文加载到内存
        // ⚠️ 切勿在生产环境或管理真实资金的私钥上使用此模式
        // ⚠️ 可以假设存放在 .env 文件中的任何密钥最终都会泄露

        console.log("This is the deployer's address:", dep);

        vm.startBroadcast(pk);
        new A(address(0));

        vm.stopBroadcast();
    }
}

终端输出结果：

bash 复制代码 
$ forge script script/DeployAddr.s.sol --rpc-url http://localhost:8545
[⠒] Compiling...
No files changed, compilation skipped
Script ran successfully.

== Logs ==
  This is the deployer's address: 0x8768C6FB71815b2e8Ab6dD31b67a926781aC8f1A

4.1.2 步骤 2：计算合约 A 和 B 的地址

现在已经拿到部署者（由私钥推导）的地址，可以使用以下命令确定性地生成合约地址：

bash 复制代码 
cast compute-address <address> --nonce <value>

如，对于部署者地址 0x8768C6FB71815b2e8Ab6dD31b67a926781aC8f1A：

bash 复制代码 
cast compute-address 0x8768C6FB71815b2e8Ab6dD31b67a926781aC8f1A --nonce 1
Computed Address: 0x20cf99233e5B16Fba6B0E7bA70768d6EDe75789D

⚠️ 注意：如果使用了错误的 nonce，就会得到错误的地址。如，在上面脚本中，一旦 new A(address(0)) 部署完成（通过 EOA），部署者的 nonce 会从 0 递增到 1。

如果在那之后还用 nonce=0 来计算地址，就会与实际部署的地址不符。

另一种方法是结合 vm.getNonce cheatcode 和 computeAddress 来确定 A 和 B 的地址，如下所示：

solidity 复制代码 
// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.13;

import {Script, console} from "forge-std/Script.sol";
import {A, B} from "../src/DeployAddr.sol";
import {LibRLP} from "lib/LibRLP.sol";

contract DeployAddrScript is Script {
    A public a;
    //B public b;

    function run() public {
        uint256 pk = vm.envUint("PRIV_KEY");
        address dep = vm.addr(pk);

        console.log("This is the deployer's address:", dep);

        vm.startBroadcast(pk);

        // nonce = 0,
        new A(address(0));
        // 部署一个新的 A 实例，构造函数参数为 address(0)
        // 部署后，nonce = 1

        // 获取当前 nonce
        uint256 currentNonce = vm.getNonce(dep);

        console.log("This is the current nonce: %s", currentNonce);

        address predicted_a = LibRLP.computeAddress(dep, currentNonce);
        address predicted_b = LibRLP.computeAddress(dep, currentNonce + 1);

        console.log("predicted_a: %s", predicted_a);
        console.log("predicted_b: %s", predicted_b);

        vm.stopBroadcast();
    }
}

这是运行脚本后的终端结果：

复制代码 
Script ran successfully.

== Logs ==
  This is the deployer's address: 0x8768C6FB71815b2e8Ab6dD31b67a926781aC8f1A  
  This is the current nonce: 1

  predicted_a: 0x20cf99233e5B16Fba6B0E7bA70768d6EDe75789D  
  predicted_b: 0xca3fF2a864026daC337312142Aa71D57c7D8Dde3

4.1.3 步骤 3: 使用对应的构造函数参数（即预计算的地址）部署合约

现在，部署合约 A 和 B ，并将结果与 predicted_a 和 predicted_b 进行比较。

solidity 复制代码 
// SPDX-License-Identifier: UNLICENSED  
pragma solidity ^0.8.13;

import {Script, console} from "forge-std/Script.sol";  
import {A, B} from "../src/DeployAddr.sol";  
import {LibRLP} from "lib/LibRLP.sol";

contract DeployAddrScript is Script {  
    A public a;  
    B public b;

    function run() public {  
        uint256 pk = vm.envUint("PRIV_KEY");  
        address dep = vm.addr(pk);

        console.log("This is the deployer's address:", dep);

        vm.startBroadcast(pk);

        // 计算该地址的当前 nonce
        uint256 currentNonce = vm.getNonce(dep);

        console.log("This is the current nonce: %s", currentNonce);

        address predicted_a = LibRLP.computeAddress(dep, currentNonce);  
        address predicted_b = LibRLP.computeAddress(dep, currentNonce + 1);

        A a = new A(predicted_b);  
        B b = new B(predicted_a);

        console.log("address(a): %s", address(a));  
        console.log("predicted_a: %s", predicted_a);  
        console.log("address(b): %s", address(b));  
        console.log("predicted_b: %s", predicted_b);

        vm.stopBroadcast();  
    }  
}

运行该脚本的终端结果如下：

复制代码 
Script ran successfully.

== Logs ==
  This is the deployer's address: 0x8768C6FB71815b2e8Ab6dD31b67a926781aC8f1A  
  This is the current nonce: 1

  address(a): 0x20cf99233e5B16Fba6B0E7bA70768d6EDe75789D  
  predicted_a: 0x20cf99233e5B16Fba6B0E7bA70768d6EDe75789D  
  address(b): 0xca3fF2a864026daC337312142Aa71D57c7D8Dde3  
  predicted_b: 0xca3fF2a864026daC337312142Aa71D57c7D8Dde3

可以看到，在终端结果中，已部署的地址 a 和 b 分别与预计算的地址 predicted_a 和 predicted_b 完全一致。

5. 总结

本文探索了以太坊合约地址在不同部署方式下的预测方法。

  • 对于使用 CREATE 指令部署的合约，展示了结果地址只依赖于 部署者的地址和 nonce ------构造函数参数和字节码本身并不起作用。
  • 对于 CREATE2 ，解释了地址预测如何结合 salt 和 完整创建字节码（包含构造函数参数）的 keccak256 哈希值。
  • 最后，描述了如何使用 Foundry 脚本和 computeAddress 在链下高效预计算并部署两个相互依赖的合约。

本文提到的 EIP 有：

  • EIP-161: 定义了账户创建交易，引入了"空账户"的概念、nonce 处理规则及其清理方式。
  • EIP-1014: 引入了 CREATE2 指令。
  • EIP-2681: 定义了账户 nonce 的范围为 0 到 2^64 - 1。

参考资料

1\] RareSkills团队2025年8月博客 [How Ethereum address are derived (EOAs, CREATE, and CREATE2)](https://rareskills.io/post/ethereum-address-derivation)

热门推荐
01UV安装并设置国内源02KGG转MP3工具|非KGM文件|解密音频03【踩坑笔记】50系显卡适配的 PyTorch 安装04蜘蛛磁力 搜索引擎大全，如何使用蜘蛛磁力查找磁力链接05Qwen3-Coder 快速上手教程 | Qwen Code + Claude Code06【2025.08.06最新版】Android Studio下载、安装及配置记录（自动下载sdk）07Claude Code VSCode集成开发指南：AI编程助手完整配置082025最新国内服务器可用docker源仓库地址大全（2025年8月更新）0920个国内外主流AI绘画工具大汇总（最新免费可用~）10突破百度网盘的下载限速，两种方法教会你【超详细】