使用开源工具测试Axelar合约

在像 Axelar 这样的跨链解决方案之上构建项目有时可能很棘手，并可能导致代码中的安全问题。幸运的是，开源工具可以自动检测到许多问题或帮助测试实现。

静态分析工具

静态分析工具可以在不执行代码的情况下检测漏洞和代码质量问题。一个工具通常实现检测器，这些检测器通常使用启发式方法来执行分析。有一些用于 Solidity 的静态分析工具。我们将进一步演示最著名的工具 Slither 和一个替代工具 Wake，它实现了 Axelar 特定的检测器。

Slither

Slither 工具可以使用 Python 的集成安装程序安装：

pip3 install slither-analyzer

它提供了大量的检测器（在撰写本文时有 80 个）。然而，许多检测器与最新版本的 Solidity 不相关，并且一些检测器仅提供信息（例如，使用内联汇编块）。该工具可以使用以下命令运行：

slither project-directory

Slither 通常会打印出大量信息，但格式不是很规范。

还有一个用于 VS Code 的 Slither 扩展，但它要求开发人员手动运行检测器。

Wake

Wake 是一个由 Ackee Blockchain 开发的 Solidity 开发和测试框架。与 Slither 一样，Wake 可以使用预先准备好的检测器集执行静态分析，其中的检测器专门为构建在 Axelar 上的项目编写。Wake 可以使用以下命令安装：

pip3 install wake

检测器的数量有限，该工具的目的不是捕获所有可能的问题，而是一些特定的问题。更多的检测器正在积极开发中；所有这些都与最新版本的 Solidity 相关，并且它打印的误报检测较少。可以使用以下命令执行项目分析：

wake detect project-directory

在其他检测器中，还有一个检测器检查 Axelar Proxy/Upgradeable 合约是否以正确的方式使用。具体来说，它检查：

• 不存在多个具有相同 contractId 的代理合约。
• 不存在多个具有相同 contractId 的可升级合约。
• 对于每个代理合约，都存在一个具有相同 contractId 的可升级合约。
• 对于每个可升级合约，都存在一个具有相同 contractId 的代理合约。
• 对于每对匹配的代理合约和可升级合约，都不存在函数选择器的冲突（setup 和 implementation 函数除外，这种行为是可取的）。

最后一点确保了当用户通过代理使用给定的 selector 调用可升级合约的函数时，该函数实际上是在可升级合约上调用的。如果在代理合约上存在具有相同 selector 的函数，则会改为调用该函数。通常，这不是预期的行为。

以下假设场景说明了这种情况。 函数 proxyOwner 和 clash550254402 共享相同的 selector。用户想要执行 clash550254402 函数，但实际上运行的是 proxyOwner 函数。这使得通过代理运行 clash550254402 函数实际上变得不可能。仍然可以直接在可升级合约上调用该函数，但没有代理合约上下文（storage、balance 等），它的行为可能会有所不同。

Re-entrancy 检测器可以识别 onlyOwner 模式，并排除只能由合约所有者执行的 re-entrancies。对于每个打印的检测结果，都有一个可能不安全 的 external call 以及可以从中启动攻击的 public/external 函数列表。

对于 VS Code 用户，有一个名为 Tools for Solidity 的扩展，它在后台使用 Wake，并提供许多语言服务器功能，例如：

• 转到定义
• 查找所有引用
• 悬停
• 代码镜头，其中包含引用数量和单击标签，以生成继承和控制流图

漏洞检测器结果直接在编辑器中可视化，并且在每次代码更改后都会刷新。

静态分析工具通常可以警告代码中可能存在的问题，但也可能报告许多误报检测。另一种方法是使用简单的单元测试或更复杂的随机生成的测试套件来测试实现。

动态分析

许多测试框架允许使用 Javascript、Python 甚至 Solidity 编写测试。测试跨链项目时的一个常见问题是，通常需要模拟链 relayers 或在测试网上测试实现。幸运的是，Axelar 提供了其开发环境，称为 Axelar Sandbox。此环境为 Solidity 和 Javascript 提供编辑器，并包括现成的与 EVM 兼容的区块链、Axelar Gateway 和 Axelar Relayers。

在单个链上模拟 Axelar Gateway 通信通常是令人满意的。Ackee-Blockchain/axelar-gateway-mock 存储库包含 Axelar Gateway 的自定义实现，旨在在单个开发链上使用。AxelarGatewayMock 合约没有实现所有 IAxelarGateway 接口函数，但它实现了支持所有类型通信所需的 sendToken、callContract 和 callContractWithToken 函数。

tests/test_gateway_mock.py 文件 中给出了合约的使用示例。它是使用 Wake 测试框架编写的，但语法应该很容易理解，并且可以作为使用 AxelarGatewayMock 合约与不同测试框架的模板。

首先，必须部署 Axelar Gateways 并且每个网关必须注册其他网关。

当使用 tokens（_sendToken_和callContractWithToken 函数）时，还必须为每个 Axelar Gateway 部署一个 token 实例，并在各自的网关注册这些实例。

AxelarGatewayMock 期望 ERC20 tokens 实现具有以下签名的 mint 和 burn 函数：

然后可以直接从外部拥有的帐户或通过合约调用 sendToken、callContract 和 callContractWithToken 函数。完整的示例可在存储库中找到。

总结

测试跨链项目有其自身的缺陷，但所提供的工具可以帮助捕获常见的错误。静态和动态分析工具都应使用，以涵盖不同类型的问题。 Re-entrancy 问题通常无法使用动态分析工具发现，而检查项目特定的不变量（例如给定时间 mint 的 token 总量）无法使用静态分析检测器完成。

除了内部测试外，强烈建议执行定期的 audits。虽然没有什么可以保证 100% 安全，但使用适当的工具以及定期的 audits 可以大大降低项目容易受到严重问题攻击的可能性。

• 原文链接： ackee.xyz/blog/testing-a...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～