如何在 Etherscan 上验证您的智能合约源代码？

了解智能合约验证

1. Etherscan 上的智能合约验证确认部署的字节码与开发人员提交的人类可读源代码匹配。

2. 此过程实现透明度，允许用户和审计员检查逻辑、识别潜在漏洞并验证预期功能。

3. 如果没有验证，合约就会显示为未经验证的字节码——模糊了其行为并降低了去中心化应用程序参与者之间的信任。

4. 验证并不意味着安全或正确；它仅证明源代码与字节码的对应关系。

5. 对于许多与基于以太坊的生态系统相关的 DeFi 仪表板、代币浏览器和第三方分析平台上的列表，验证步骤是强制性的。

成功验证的先决条件

1. 您必须能够访问部署期间使用的准确 Solidity 编译器版本，直至补丁级别（例如 v0.8.19+commit.7dd6d404）。

2. 优化设置（包括运行次数）必须与原始编译环境中配置的相同。

3. 如果合约是使用参数部署的，则构造函数参数必须正确进行 ABI 编码，并附加到部署的字节码中。

4. 所有导入的依赖项（例如 OpenZeppelin 库或自定义接口）必须扁平化或在单个文件中提供或通过具有正确路径映射的多文件上传来提供。

5. 合约名称必须与源文件中定义并在部署期间使用的合约名称匹配，包括区分大小写和下划线。

分步手动验证过程

1. 使用其部署地址导航到合约的 Etherscan 页面，然后单击“代码”选项卡，然后单击“验证并发布”。

2. 从下拉菜单中选择正确的编译器版本 - 不匹配的版本将导致立即失败。

3. 选择合适的许可类型；选择“无”或不兼容的许可证可能会触发警告或拒绝。

4. 将完整的扁平化源代码粘贴到编辑器中，或使用“上传文件”选项来获取具有准确目录结构的多文件合同。

5. 如果适用，以 ABI 编码的十六进制格式输入构造函数参数 — Remix IDE或ethers.js 实用程序等工具可帮助生成此值。

常见验证失败及修复

1. 当选定的 Etherscan 版本与部署时使用的版本不同时，就会出现“编译器版本不匹配”错误——即使像 +commit 哈希这样的微小差异也很重要。

2. 当十六进制字符串格式错误、太短或包含非十六进制字符时，会出现“无效的构造函数参数”；始终使用ABI 编码器工具进行验证。

3. 当 SPDX 标签丢失或格式错误时，会出现“未找到许可证标识符”的情况 - 在每个源文件的顶部包含// SPDX-License-Identifier: MIT 。

4. “源代码包含语法错误”表示不完整的扁平化或未解析的导入——在提交之前使用solc-flattener或 Hardhat 的内置扁平化任务。

常见问题解答

问：我可以验证通过工厂模式部署的合约吗？答：是的，如果您知道传递给工厂的创建函数的确切字节码和构造函数参数。您必须单独验证子合约地址，而不是工厂本身。

问：Etherscan 支持 Vyper 或其他语言吗？答：Etherscan 支持 Vyper 验证，但需要选择正确的 Vyper 编译器版本并提供编译后的 JSON 输出以及源代码。

问：如果我丢失了原来的编译设置会怎样？答：您通常可以使用sourcify.dev等工具或通过使用 Hardhat 或 Foundry 缓存目录中的构建工件重新编译来恢复它们。

问：Arbitrum 或 Optimism 等 L2 链上部署的合约是否可以进行验证？答：是的，每个 Etherscan 品牌的浏览器（例如 arbiscan.io、optimismscan.io）都提供针对各自网络量身定制的相同验证流程。