Wake：Solidity的开发与测试框架

注意：Woke 已更名为 Wake。

今年我们推出了 Solidity 工具，这是一个 Visual Studio Code Solidity 扩展，它在后台与我们的 Solidity 开发和测试框架 Wake 一起运行。

我们不断更新这两个工具，使它们更好，并使开发人员和安全审计员的工作更轻松。 2 月 7 日，我们发布了 Wake 的一个新主要版本——Wake 2.0， 它引入了我们 从头开始编写的全新测试框架。 我们特别关注 测试框架的性能以及用户体验。

从一开始，该框架就被设计为 支持跨链测试并与我们的模糊测试器一起使用。 现在发布后，我们正在准备该框架的首次更新，该更新将 带来编写部署脚本的能力。 还会有一些 性能和稳定性方面的改进。

在对 我们的首席开发人员 Michal Převrátil 的采访中，了解为什么这些工具对你可能有用，以及即将推出的其他改进。

你能简要描述一下“Solidity 工具”扩展的架构吗？

我们的扩展就像任何其他用 JavaScript/TypeScript 编写的 VS Code 扩展一样。但是，与大多数扩展不同，它不包含所提供所有功能的实现。事实上，只有最必要的部分是在扩展中实现的，我们通过 LSP 协议将所有代码分析请求委托给我们的 Wake 工具。

这有其优点和缺点。缺点 是我们必须以某种方式在用户的机器上安装 Wake，维护所需的版本并在扩展启动时运行它。优点 是所有分析和使用 Solidity 代码的工作都只使用一个工具完成，该工具独立于扩展工作。这也让我们更容易将 LSP 功能扩展到其他开发环境，例如 Jetbrains Fleet。

它与其他扩展（特别是 Hardhat）有何不同？为什么有人会使用它？

从一开始，我们就知道还有其他支持 Solidity 的扩展。但是，我们对它们不满意： 分析工作不可靠，通常需要同时使用多个扩展，但效果并不总是很好。我们希望提供开发人员和审计员都会欣赏的功能。这些包括 转到定义、查找所有引用，以及显示编译器警告和错误。一个很大的目标是在代码中添加错误/漏洞检测器，每当代码发生更改时，这些检测器都会自动高效地触发。我敢说我们已经 成功完成了开发的第一阶段。

我认为 Nomic Foundation (Hardhat) 的一个名为 Solidity 的扩展是一个强大的竞争对手。我们在 转到定义、查找所有引用 或 重命名 等功能上有很大的重叠。我们注意到我们的一些小东西做得更好。例如，我们对 悬停功能 有稍微更精确的标签（当用户将光标悬停在变量上时），并且我曾多次遇到他们的语言服务器不适用于局部变量的情况。在提供的额外功能方面，我绝对想重点介绍 文档符号（如下图所示），它清楚地显示了一个目录，即给定文件的已声明对象列表。

此外，我们可以 列出引用数量 （此声明的使用）在每个声明上，并为函数生成控制流图，为合约生成继承图（线性化和树状结构），并在声明上有意义的地方，我们列出通过单击复制到剪贴板的选择器。生成图需要安装用于渲染 Graphviz DOT 图的支持扩展之一。我们不想将一个特定的扩展强加给用户 🙂

总的来说，对我来说，Wake（或 Solidity 工具）的一个伟大之处在于 它在常见情况下可以开箱即用。这意味着当项目打开时，我们的扩展和 Wake 会启动，并且编译和检测器已经在运行。通常 不需要配置。 另一方面，Hardhat 扩展需要一个配置文件，没有该配置文件，扩展不会显示编译器输出（警告和错误）。

自动完成是我们尚未实现的功能之一（但 Hardhat 扩展实现了），但是它有很多限制。我想我知道这些原因，我们也有同感。也就是说，一旦用户修改代码，使其无法编译（例如，用户尚未编写代码行），我们就会丢失所有分析信息。但是，我们可以依赖先前成功编译的信息，该编译可能在不久前发生。从用户的角度来看，这意味着他们删除一个分号或一个导入指令，并丢失所有 LSP 功能。我知道这将对 Solidity 开发人员的效率产生重大影响，因此我们为当前无法编译（但之前有时会编译）的文件中某些 LSP 功能提供了实验性支持。这只是启发式方法，因此无法在 100% 的情况下正确工作。尽管如此，根据我们的经验，它的效果非常好，我为此感到自豪。在我看来，这是尝试我们的扩展的最有力的理由之一。我不知道有任何 Solidity 扩展支持不可编译的源文件。

最后，我们意识到我们的扩展无法完成所有工作，如果用户缺少某些功能，则始终可以尝试一次使用多个扩展。或者在我们的 Github 上打开一个功能请求：这里 或 这里。

Solididity 团队也在准备一个 LSP 服务器。实现方式有何不同？

我知道在 solc 编译器中实现 LSP 服务器。我不得不承认，在目前的情况下，这似乎不是一个最好的主意。他们的 LSP 服务器功能与 solc 编译器版本相关联，他们可以在每个编译器版本中添加新功能，但他们不能再向早期编译器版本添加新功能。换句话说，对于不是为最新编译器版本设计的 Solidity 代码，编译器将根本无法提供 LSP 分析，或者只能在非常有限的范围内提供。此外，我无法想象当源文件必须在一个项目中使用多个版本的编译器进行编译时，情况将如何处理。此外，他们在实现 LSP 服务器方面的进展对我来说似乎相当缓慢。我真诚地希望看到一个更稳定、更快的编译器，错误更少，并反过来更好地支持构建在其输出之上的工具。

例如，在开发 Wake 时，我们必须为作为编译器输出的 AST（抽象语法树）模型编写自己的文档 🙂 顺便说一句，它目前在 这里 的 IR 模型选项卡下提供，但在未来，此文档将集成到主开发分支中（即它将在 这里）。

这些工具的下一步是什么？它们面向哪些用户？

我们对这两个工具（Solidity 工具和 Wake）都有很大的计划，这要归功于我们从 Coinbase 获得的资助才得以实现。

我们目前正在 Wake 中实现我们自己的测试框架，这使我们能够有效地用 Python 为 Solidity 合约编写测试。通过将 Solidity 对象（合约、结构体、枚举等）的类型信息生成到 Python 中，我们能够在 编写测试时提供自动完成功能，因此审计员/开发人员甚至不需要查看 Solidity 源文件。事务执行速度 也是一个优先事项。我们目前提供一个基于 Brownie 测试框架的基于属性的模糊测试器，但我们对其性能不满意。这也是我们决定开发自己的测试框架的原因之一：我们想修复我们在 Brownie 中看到的错误。就我们的测试框架的性能而言，我可以透露结果非常有希望。这主要是因为我们使用 anvil 作为我们的 EVM 后端（开发链）。

我们还计划向 Wake 添加更多检测器，并根据反馈和我们自己的需求扩展我们的扩展（或 LSP 功能）。总的来说，我认为扩展是通过更友好的（即非终端）环境向更广泛的用户群体提供 Wake 功能的好方法。这也与工具的目标群体有关：Wake 应该更多地为安全分析师、审计员而设计。另一方面，Solidity 开发人员可能更喜欢我们的扩展。但是，我个人更喜欢这两种工具的组合。

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