我正在开发一个网络应用程序，两个玩家通过以太坊区块链上的智能合约进行交互。该应用程序的工作流程如下：
为了确保公平性，第二个玩家验证部署的合约是否是商定的版本，没有任何修改，这一点至关重要。
为了解决这个问题，我实现了基于 getBytecode 函数的
字节码比较机制，该机制使用
eth_getCode作为后备措施，我开始使用 Etherscan API 来检索合约的经过验证的源代码。不幸的是，我注意到在合约部署后过早查询 API 可能会导致它匹配不正确的合约（！！）。这引发了人们对为此目的使用 Etherscan API 的可靠性以及依赖它的潜在风险的担忧。
节点仅保留最近数量的块的字节码信息
这对于启用了 pruning 选项的节点是正确的。
未经剪枝的节点保留所有合约的字节码。
此选项可由节点运营商配置。未修剪的节点需要多倍的磁盘空间，这就是它们不太常见的原因之一。话虽如此，大多数第 3 方节点提供商仅在其免费和较低层计划中提供修剪的节点，而未修剪的（甚至存档 - 具有所有历史状态） 节点通常位于较高层。
除了中心化风险之外，用于检索源代码的 Etherscan API 是否适合此类任务？
正如您所提到的，即使您正在寻找完全匹配，第三方 API 也可以返回类似的结果。
如果您有预期的字节码，则与节点检索到的确切字节码进行比较通常更安全。
如果您仍想使用第 3 方 API 比较源代码，请确保比较源代码是否与预期输入完全匹配。尽管可能存在误报，例如如果原始代码使用制表符而比较使用空格，或者如果副本的作者决定添加原始代码中不存在的注释，...因为字节码“只是”二进制文件、制表符/空格和注释对生成的二进制文件没有影响。
有没有我忽略的常识或方法？
我不知道任何具体的常识或其他方法。但关于验证合同来源还有一个注意事项：
任何人都可以部署相同的合约，但向其传递不同的构造函数参数。它们存在于 init 字节码（传递给部署交易）中 - 但不存在于 运行时字节码（部署合约后存储在 EVM 中）。
如果您的应用程序可能容易受到这种攻击，您可能需要考虑使用工厂模式来部署合约：
工厂合约包含将特定目标合约部署到新地址的功能。
用户调用工厂合约而不是直接部署目标合约
a.目标合约的新实例部署在新地址上（通过工厂） b.工厂存储新部署目标的地址
您的应用程序根据工厂中存储的有效目标合约列表进行验证