以太坊协议共学｜第四周内容回顾：EPFsg 测试和安全说明
点击蓝字，关注我们
/ 撰文（英） Chloe
/ 编译 Purple
0. 目录
分享嘉宾 - Mario Vegas（以太坊基金会测试&安全团队）
Mario Vega：https://twitter.com/elbuenmayini
执行层测试
EVM 测试
主要目的：验证每个执行客户端都遵守规范，否则会导致链中潜在的正分叉
设置：在给定相同的环境、预设、硬分叉激活规则的情况下，为每个客户端提供相同的输入，并期望从每个客户端获得相同的输出
测试的重要特征：
预状态：整个以太坊链的组成，由具有余额、随机数、代码和存储的帐户组成
环境：根据测试的类型，环境可以指定诸如时间戳、先前的 RANDAO、区块编号、先前的区块哈希值、总 Gas 限制、基本费用和硬分叉激活时间等内容。
交易：发送到区块链的消息，在区块链上执行操作，其中包含源帐户和目标帐户、以太值、Gas 限制和数据
后状态：由修改或创建的帐户组成的结果状态
EVM 测试 - 测试填充
测试填充的定义：将测试源代码编译成可由任何执行客户端使用的固定的过程
测试填充 vs 客户端单元测试：对于测试填充，可以在任何客户端实现中执行完全相同的测试。而对于客户端单元测试，不同的客户端团队之间可能会有所不同。
功能：不同格式的所有测试装置都是单个 JSON 文件，可供每个客户端使用
EVM 测试格式
状态测试
使用状态根（state root）进行验证：给定相同的预状态和相同的交易，不同的客户端应该返回相同的状态根
状态根：安全提交状态所有内容的加密计算
模糊微分状态测试
在设计的交易之上，将使用 FuzzyVM 工具添加模糊的智能合约代码。不同的客户端仍应返回相同的状态根。
区块链测试
由于我们在执行层客户端上检查的所有内容，并非都是 EVM 执行的一部分，例如前一个区块的执行结果、1559 基本费用等，因此还需要进行完整的区块测试来验证客户端的执行情况。
区块链负面测试
在某个时刻添加无效块，以检查客户端是否可以出于设计目的拒绝无效块，返回到之前的有效块并将其声明为链头。
测试填写详细信息
以太坊/测试
代码仓库链接：https://github.com/ethereum/tests
特征
简单的 JSON 和 YAML 源代码
提供简单的参数化
由 Retesteth 填充（用 C++ 编写）
以太坊/执行规范测试
代码仓库链接：https://github.com/ethereum/execution-spec-tests
特征
Python源代码
由 pytest 提供支持，并提供简单到复杂的参数化
由于转换功能，仍然需要实际的客户端实现来填充
执行规范测试
从包含所有书面参数化的 Python 测试 开始
目前，从 frontier 到 cancun，每个分叉都有一个 python 测试
3 个依赖项
Evm t8n: Geth 子命令 evm t8n
原理：由于测试用例是用 Python 编写的，开发人员需要执行客户端来提供实际的客户端实现
命令输入：所有预状态、交易和环境
输出：执行的结果
Solidity: （开发人员在测试中越来越少使用）
仅当存在开发人员无法通过字节码编写完成的非常复杂的代码时才使用 Solidity
EIP/ EIPs: 开发编写测试时规范的主要来源
填充命令：$ fill ./tests/
输入：python 测试用例，以及上面的 3 个依赖项
输出：客户端可使用的 JSON 测试装置，用于 3 种状态，包括。Hive 中的状态测试、块测试和块测试
两个主要子存储库：源代码和测试
源代码：https://github.com/ethereum/execution-spec-tests/tree/main/src
框架的源代码，即开发人员用来填充测试的代码
src 内没有测试
测试：https://github.com/ethereum/execution-spec-tests/tree/main/tests
包括：硬分叉测试，从 frontier 到 cancun
由于 ethereum/execution-spec-tests 代码仓库是从上海升级开始激活的，故上海和坎昆对所有 EIP 都进行了测试，而对于之前的 EIP，完整测试将在 ethereum/tests 存储库中
FuzzyVM
代码仓库链接：https://github.com/MariusVanDerWijden/FuzzyVM
fuzz EVM 实现的框架
FuzzyVM 创建状态测试，可用于相互区分 Fuzz EVM 实现
它只关注测试生成部分，测试执行部分由 Go evmlab处理
执行 API 测试
代码仓库链接：https://github.com/ethereum/execution-apis/tree/main/tests
测试用于查询执行客户端的所有执行 API
共识层测试
代码仓库链接：https://github.com/ethereum/consensus-specs/tree/dev/tests
特征
生成所有客户端都可以使用的不同格式的测试装置方面的类似想法
在规范中独立，因此可以在同一个存储库中编写和填写测试，而不依赖于任何共识层客户端
用 Python 编写
共识层测试的格式
仓库：https://github.com/ethereum/consensus-specs/tree/dev/tests/formats
共识层测试的格式比 EVM 的测试格式更多。对于开发人员来说，对共识层的各个方面进行精细化测试非常有用。
跨层（互操作）测试
特征
涉及测试完全实例化的客户端、向其提供信息并验证其行为的正确性
基本上，它正在构建从 Genesis 到某个点的链，然后验证执行层和共识层之间的所有交互是否都正确发生
Hive
Repo link: https://github.com/ethereum/hive
Hive 是一个针对以太坊客户端运行集成测试的系统
Hive 与其他通用共识层基础设施的不同之处在于以太坊客户端及其功能的紧密集成
Hive 的工作流程
构建 Hive 服务器并启动它
Hive 服务器将启动给定的模拟器，其中包含有关如何运行测试的所有说明。模拟器的工作是知道何时开始和结束测试、如何、何时开始和结束客户端等。
不同的 Hive 模拟器
代码库链接: https://github.com/ethereum/hive/tree/master/simulators
开发者网络
用于验证概念证明，或硬分叉早期阶段的有限节点数链
Shawdow Fork
有限的节点数 Fork 的配置遵循以太坊主网，但有一个早期的硬分叉配置时间来测试真实的网络活动
公共测试网
Goerli 测试网（已弃用）
Sepolia 测试网（于 2021 年 10 月 23 日启动）
Holesky 测试网（2023 年 9 月 28 日启动）
安全
潜在问题
执行层一侧
有效失效：执行客户端使完全符合以太坊规范的区块失效
无效验证：执行客户端验证了不符合以太坊规范的块
区块执行期间的 DoS：由于交易，客户端花费太多时间来处理区块
共识层一侧
错误的客户端和最终确定
<33% 故障节点多数：可能导致错过时隙，但链仍将最终确定
33%以上的故障节点多数：可能导致延迟最终确定
50%以上的故障节点多数：可能会破坏分叉选择
66%+ 故障节点多数：可以最终确定一条不正确的链
漏洞赏金
链接：https://ethereum.org/en/bug-bounty/
公开披露
链接：https://github.com/ethereum/public-disclosures
问答
由于 EVM 测试需要 Geth 实现来填充测试，如果 Geth 的代码有 bug 怎么办？或者如何确保没有 bug？
理想情况下，开发人员不想依赖 Geth 的实现。开发人员目前正在开发另一个面向规范的存储库，以便将来的测试归档将不再依赖于 Geth。
共识层和执行层中要测试的最复杂的部分是哪一个？运行所有这些测试需要多少时间？
互操作性是最复杂的部分
EVM 本身也很复杂，因为执行过程中有很多细微差别，需要多次来回测试。
关于时间，取决于运行测试的硬件。目前，并行运行执行规范测试需要 5-10 分钟
如何向客户端传达错误？
这取决于错误的严重程度。如果该错误影响任何实时网络，我们将谨慎处理，例如与特定开发人员沟通或通过特殊沟通。
推荐阅读
以太坊协议共学｜第三周内容回顾：Consensus Layer
/ About Plancker
PlanckerDAO 是一个专注建设以太坊生态的社区，我们为开发者、产品经理和研究员提供多方面支持，致力于与以太坊共建人类的数字化美好未来。
Website：https://plancker.org/
Forum：http://forum.plancker.org/
Telegram：https://t.me/PlanckerDAO
Notion：https://planckerdao.notion.site/
Twitter：https://twitter.com/PlanckerDAO