同一智能合约经Truffle与solc编译生成不同字节码的原因及解决方法

问题背景 #

我有一个名为SimpleContractB的智能合约，代码如下：

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.11;

contract SimpleContractB {
  function example1() public returns(bool, bytes memory) {
    (bool isSuccess, bytes memory data) = address(msg.sender).call{ value: 1 ether }("");
    return (isSuccess, data);
  }

  function example2() pure public {
    revert("Demo internal transaction error!");
  }

  function example3() payable public {
    assert(msg.value > 1 ether);
  }

  function example4() payable public {
    require(
      msg.value > 1 ether,
      "Not enough Ether provided."
    );
  }
}

使用版本：Truffle v5.6.8、solc-js v0.8.11+commit.d7f03943

遇到的问题：该合约经Truffle编译生成的字节码与solc直接编译生成的字节码不一致，差异位置如下：

• Truffle生成的字节码片段：

  ...2122.09eaba953a1c59544a9531febfd70e08b13bb5df89f10bd47b60c91f15a6aa9c1.64736f6...
  

• solc生成的字节码片段：

  ...2122.0d049f2c7420c99ed39feca36ba29c813ce6344f3aea16f5116a9ea9ca15bbd4e.64736f6...
  

原因分析 #

• 编译参数与默认配置差异：Truffle编译时会默认启用特定优化选项或传递额外参数（比如EVM版本、优化次数），而直接用solc编译时如果未匹配这些参数，会导致字节码差异。
• 元数据哈希不一致：Solidity字节码末尾会附带元数据哈希，该哈希包含编译上下文（如文件路径、编译配置细节）。Truffle编译时的文件上下文和直接solc编译的上下文不同，会导致元数据内容变化，进而改变哈希值，这也是你看到的差异区域。
• 版本细节差异：即使主版本一致，Truffle内置的solc可能和你单独使用的solc-js存在细微的版本分支差异，也会影响字节码生成结果。

解决方法 #

• 统一编译参数：在Truffle的truffle-config.js中明确配置编译器参数，确保和solc编译时的参数完全一致。示例配置：

  module.exports = {
    compilers: {
      solc: {
        version: "0.8.11",
        settings: {
          optimizer: {
            enabled: false, // 和solc默认状态匹配，或按需设置
            runs: 200
          },
          evmVersion: "london" // 匹配solc使用的EVM版本
        }
      }
    }
  };
  

  同时用solc编译时传递相同参数：

  solc --evm-version london --optimize --optimize-runs 200 SimpleContractB.sol --bin
  

• 忽略元数据哈希对比：如果仅验证合约核心执行逻辑，可忽略字节码末尾64个字符的元数据哈希部分，核心逻辑区域的字节码应保持一致。
• 使用Truffle内置solc：通过truffle compile --list查看Truffle内置的solc版本路径，直接使用该路径的solc进行编译，确保版本完全匹配。

内容的提问来源于stack exchange，提问作者Augustus Flynn