EIP-7619 Falcon-512 预编译验证器测试向量指南从无效输入矩阵到 100 组基准数据【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPsEIP-7619 提议在 EVM 地址0x65部署一个 Falcon-512 通用签名验证预编译合约Standards Track / Core当前状态 Draft使智能合约可以低 Gas 成本地验证 NIST 候选后量子签名算法 Falcon-512 的签名。本指南以该提案在仓库中配套的三份测试资产为核心逐项解析100 组有效签名基准向量、15 组无效数据测试向量与5 秒基准测试结果说明这些向量如何验证预编译的行为契约、如何用于新实现的测试与基准回归。读完本文你将能够基于 EIPS/eip-7619.md 与 assets/eip-7619/ 下的原始数据独立搭建 Falcon-512 预编译的合规测试与基准流程。预编译契约回顾输入、输出与出错语义在进入测试向量之前先明确被测试对象的行为契约出自 EIPS/eip-7619.md 的 Specification 小节地址0x65输入编码verify(bytes,bytes,bytes)的 calldata ABI 形式[pubkey:897 bytes][signature:666 bytes][message: remainder]三个输入分别为 Falcon-512 公钥897 字节、签名最大 666 字节与任意长度的被签名消息输出成功返回0000000000000000000000000000000000000000000000000000000000000001其余失败情况在提供了充足 Gas 的前提下返回全零最重要的出错语义数据格式错误、尺寸错误、无效签名都不会导致预编译 revert只有Gas 不足才会 revert。这一点正是无效签名测试向量设计的基石。配套的 Solidity 封装同见于 EIP 正文通过staticcall调用0x65并检查success verifies.length 32后取verifies[31] 1作为验证结果——这正是测试向量返回值的消费方式。测试资产总览仓库在 assets/eip-7619/ 下维护了三份互相配套的资产文件内容用途assets/eip-7619/bench_vectors.md100 组格式正确、签名有效的向量JSON 数组新实现的功能正确性验证 基准测试输入assets/eip-7619/invalid_signature_test_vectors.md15 组无效数据向量自定义记录格式验证“格式错误不 revert”的契约assets/eip-7619/benchmark_results.mdgo test benchmark 输出定价模型的实验依据1465 gas 基础 6 gas/word它们在 EIP 正文的 Test Cases 与 Gas costs 小节中被正式引用是提案可复现性的一部分。100 组有效签名基准向量结构与生成方式bench_vectors.md 中内联了一个包含 100 个元素的 JSON 数组每个元素形如{ Input: de8f50a1..., Expected: 0000000000000000000000000000000000000000000000000000000000000000, Gas: 1, Name: Vector 0, NoBenchmark: false }几个关键事实来源这些向量基于 falcon-sign.info 的官方 Falcon 测试向量。按文档说明原始向量通过abi.encodeWithSignature编码为verify(bytes,bytes,bytes)调用即 4 字节函数选择器后接 ABI 动态参数区选择器所有向量的Input都以de8f50a1开头。通过对向量程序化解码可以确认de8f50a1正是verify(bytes,bytes,bytes)的 ABI 函数选择器三参数偏移在 100 组向量中三个动态参数的偏移字段全部固定为0x6096、0x320800、0x6e01760。其中位于第二个数据区的长度字段固定为897与 EIP 规范中 Falcon-512 公钥的 897 字节完全一致说明布局与规范输入[pubkey][signature][message]相互印证消息递增文档明确说明“每个向量的大小增加 33 字节”对应消息数据随 Vector 序号逐步增长如 Vector 0 与 Vector 99 的总输入长度差异约 3 KB目的是让 Gas 成本随数据量变化从而拟合出“每 word 额外计费”的线性模型Expected 字段100 组向量全部标注Expected 0x…00。注意这与无效向量文件的标注值0x…01恰好相反两个文件的Expected字段语义各自独立接入测试框架时需以实现约定的返回值映射为准——EIP 正文中定义的成功返回值是…01、失败是…00而这两个向量文件中的Expected值分别与基准/失败场景绑定应按各自文件的注释与测试目标理解不要混用Gas与NoBenchmark基准向量集中每个元素都带Gas: 1、NoBenchmark: false两个字段供基准程序Go 基准测试读取后跳过/执行对应向量——NoBenchmark: false表示该向量应参与基准。一个基准向量的 ABI 解剖以 Vector 0 为例Input去掉选择器de8f50a1后的 payload 区可解码为已由脚本验证word 索引内容含义00x60第一个参数的偏移9610x320第二个参数的偏移80020x6e0第三个参数的偏移17603656第一个数据区的长度25897第二个数据区的长度 Falcon-512 公钥大小5533第三个数据区的长度Vector 0 的消息长度随向量递增这与 EIP 规范中[pubkey:897][signature:666][message]的尺寸设定吻合可作为校验向量完整性的快速手段。15 组无效数据测试向量不 revert 契约的分层验证invalid_signature_test_vectors.md 中内联了 15 组向量标题写明其用途是“验证一些无效签名情形”。每组记录的格式为{ Input: de8f50a1..., Expected: 0000000000000000000000000000000000000000000000000000000000000001, Name: vector N: 描述, }对全部 15 组Input的程序化解码结果如下它们共同构成了对预编译输入校验逻辑的系统性攻击面测试阶段一方法选择器之后的头帧缺陷Vector 0–1向量Name实际输入形态缺陷类型0No data after method signature仅de8f50a14 字节选择器后无任何参数数据1No enough data after method signaturede8f50a1abc5 字节选择器后只有 3 字节、不足一个 32 字节 word这两组验证即使 payload 完全缺失或只有残片预编译也必须正常返回而非 revert。阶段二三个偏移字段归零Vector 2–4向量Name被置零的偏移2Signature offset is zero第一个参数偏移0x60 → 0x003Public key offset is zero第二个参数偏移0xa0 → 0x004data offset is zero第三个参数偏移0xe0 → 0x00解码确认三组的长度区分别把0x60、0xa0、0xe0替换为0x00测试 ABI 动态偏移为零时的容错。阶段三签名区长度异常Vector 5–7向量Name签名区形态5signature length not present in input长度字段缺失payload 只有 100 字节不足以容纳长度字6signature length is present but its value is zero长度字段存在但为 07Signature indicated length is too long长度字段为0x600000000远超 666 字节上限阶段四公钥区长度异常Vector 8–10向量Name公钥区形态8public key length not present in input只有 32 字节占位数据0x11…11无长度字段9public key length is present but its value is zero长度字段为 010Public Key indicated length is too long长度字段为0x80000000000000远超 897 字节阶段五消息区长度异常Vector 11–13向量Name消息区形态11data length not present in input只有 32 字节占位数据0x22…22无长度字段12data length is present but its value is zero长度字段为 013Data indicated length is too long长度字段为0x5000000000000000Vector 8–13 的占位数据是0x1111…11/0x2222…22这种可辨识的填充模式便于在测试日志中快速定位是哪一段数据引发了路径分叉。阶段六格式正确但签名本身无效Vector 14Vector 14payload 约 1851 字节是 15 组中唯一携带真实 Falcon 材料的一组描述为“Correct format but invalid Signature”。解码显示它具备完整的三参数帧偏移0x60/0x312/0x6b3与对应的长度字段签名数据被替换为与公钥/消息不匹配的伪签名——它专门测试“数据形状完全合法但密码学验证失败”时预编译返回失败值而非 revert 的行为与 EIP 正文“invalid signatures will not cause the precompile to revert”的约定直接对应。统一断言全部不 revert15 组向量的Expected全部标注为…01结合 EIP 正文“数据格式错误、尺寸错误、无效签名均不导致 revert”的规范这组向量的预期行为是每一种畸形输入都应得到一次正常的、不 revert 的预编译调用。实现方接入时应按此语义编写断言调用成功、返回 32 字节、且无 out-of-gas 以外的异常而不是把Expected直接当作密码学验证结果。5 秒基准结果Gas 定价模型的实验来源benchmark_results.md 记录了在Intel(R) Core(TM) i7-10750H CPU 2.60GHzLinux/amd64go test 12 路并行上执行的 Go 基准测试pkg: github.com/ethereum/go-ethereum/core/vm BenchmarkPrecompiledEcrecover/-Gas3000-12 61453 91486 ns/op 3000 gas/op 32.79 mgas/s 800 B/op 7 allocs/op BenchmarkPrecompiledFalcon512/Vector_0-Gas2101-12 100734 56717 ns/op 2101 gas/op 37.04 mgas/s 2520 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_1-Gas2106-12 101684 56510 ns/op 2106 gas/op 37.26 mgas/s 2520 B/op 11 allocs/op ... BenchmarkPrecompiledFalcon512/Vector_99-Gas2611-12 77630 72218 ns/op 2611 gas/op 36.15 mgas/s 5848 B/op 11 allocs/op可以从该结果中提取的关键信息对照基线以假定定价完全合理的ecRecover预编译3000 gas、约 91.5 µs/op为参照系每向量 Gas 递增Falcon512 基准从Vector_0 - Gas2101开始每个后续向量增加 5~6 gas如 2101 → 2106 → 2111 → … → 2611正好对应“每个 32 字节 word 追加计费”的模型性能区间Falcon512 单次验证约 56–83 µs/op吞吐约 29.9–38.6 mgas/s在测试机器上多数向量快于 ecRecover 的 91 µs内存特征B/op 从 2520 逐步增长到 5848allocs/op恒为 11说明分配次数与向量尺寸无关、分配总量随消息长度线性增长定价结论EIP 正文说明将 100 组BenchmarkPrecompiledFalcon512结果近似为关于输入字节数的线性方程后得到1465 gas 基础费用 每 word32 字节6 gas。该结论被直接写入 EIPS/eip-7619.md 的 Gas costs 小节。实战如何把这套资产用起来1. 功能测试无效输入矩阵对 15 组 invalid 向量逐一执行将十六进制Input解析为 calldata以Gas: 10之类极低 Gas 执行一次应得到out of gas对应 EIP 中 “empty input, too little gas” 的示例以充足 Gas 执行断言调用成功、未 revert、返回长度 32 字节、返回值与向量Expected相符对每组向量在断言信息中带上Name字段如vector 7: Signature indicated length is too long便于失败定位。2. 基准回归100 组有效向量将 bench_vectors.md 的 JSON 数组解析为测试用例列表按Name/Gas字段组织 Go benchmark命名风格可对齐BenchmarkPrecompiledFalcon512/Vector_N-Gas…对每个向量运行固定时长如 5 秒取样记录 ns/op、gas/op、mgas/s、B/op、allocs/op。3. 定价模型校验基准完成后把 100 组结果的 ns/op 或 gas/op 对输入字节数做线性回归斜率应接近“每 word 6 gas”、截距应接近 1465。若你的实现截距/斜率显著偏离说明底层 Falcon-512 实现EIP 正文注明其实现源自 PQClean 项目的常数开销或数据访问模式与提案预期不同需要复核。4. 与 Solidity 封装联调EIP 正文给出的包装函数verify(bytes,bytes,bytes)会校验success verifies.length 32并以verifies[31] 1作为布尔结果。测试时可以把无效向量喂给该封装预期调用不抛Invalid signature的require失败因为预编译不 revert而是返回false把基准向量喂给封装则返回true——这是两个文件Expected 分别为…00/…01在应用层的正确汇合点。小结EIP-7619 用三份相互配套的资产把“Falcon-512 预编译行为契约”变成了可机器验证的规格bench_vectors.md用 100 组源自官方 Falcon 测试向量的有效输入同时承担功能验证与 Gas 定价回归invalid_signature_test_vectors.md用 15 组分层构造的畸形输入缺失、截断、偏移归零、长度为零、长度超界、真材实料的伪签名锁定“不因数据错误 revert”这一关键语义benchmark_results.md则给出 1465 6 gas/word 定价模型的实验数据链。理解这三份文件就等于同时理解了 EIP-7619 的输入输出规范、容错边界与性能预算可以据此为新实现编写出一致、可复现的合规测试。【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 EIP-7619 Falcon-512 预编译验证器测试向量指南：从无效输入矩阵到 100 组基准数据
EIP-7619 Falcon-512 预编译验证器测试向量指南从无效输入矩阵到 100 组基准数据【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPsEIP-7619 提议在 EVM 地址0x65部署一个 Falcon-512 通用签名验证预编译合约Standards Track / Core当前状态 Draft使智能合约可以低 Gas 成本地验证 NIST 候选后量子签名算法 Falcon-512 的签名。本指南以该提案在仓库中配套的三份测试资产为核心逐项解析100 组有效签名基准向量、15 组无效数据测试向量与5 秒基准测试结果说明这些向量如何验证预编译的行为契约、如何用于新实现的测试与基准回归。读完本文你将能够基于 EIPS/eip-7619.md 与 assets/eip-7619/ 下的原始数据独立搭建 Falcon-512 预编译的合规测试与基准流程。预编译契约回顾输入、输出与出错语义在进入测试向量之前先明确被测试对象的行为契约出自 EIPS/eip-7619.md 的 Specification 小节地址0x65输入编码verify(bytes,bytes,bytes)的 calldata ABI 形式[pubkey:897 bytes][signature:666 bytes][message: remainder]三个输入分别为 Falcon-512 公钥897 字节、签名最大 666 字节与任意长度的被签名消息输出成功返回0000000000000000000000000000000000000000000000000000000000000001其余失败情况在提供了充足 Gas 的前提下返回全零最重要的出错语义数据格式错误、尺寸错误、无效签名都不会导致预编译 revert只有Gas 不足才会 revert。这一点正是无效签名测试向量设计的基石。配套的 Solidity 封装同见于 EIP 正文通过staticcall调用0x65并检查success verifies.length 32后取verifies[31] 1作为验证结果——这正是测试向量返回值的消费方式。测试资产总览仓库在 assets/eip-7619/ 下维护了三份互相配套的资产文件内容用途assets/eip-7619/bench_vectors.md100 组格式正确、签名有效的向量JSON 数组新实现的功能正确性验证 基准测试输入assets/eip-7619/invalid_signature_test_vectors.md15 组无效数据向量自定义记录格式验证“格式错误不 revert”的契约assets/eip-7619/benchmark_results.mdgo test benchmark 输出定价模型的实验依据1465 gas 基础 6 gas/word它们在 EIP 正文的 Test Cases 与 Gas costs 小节中被正式引用是提案可复现性的一部分。100 组有效签名基准向量结构与生成方式bench_vectors.md 中内联了一个包含 100 个元素的 JSON 数组每个元素形如{ Input: de8f50a1..., Expected: 0000000000000000000000000000000000000000000000000000000000000000, Gas: 1, Name: Vector 0, NoBenchmark: false }几个关键事实来源这些向量基于 falcon-sign.info 的官方 Falcon 测试向量。按文档说明原始向量通过abi.encodeWithSignature编码为verify(bytes,bytes,bytes)调用即 4 字节函数选择器后接 ABI 动态参数区选择器所有向量的Input都以de8f50a1开头。通过对向量程序化解码可以确认de8f50a1正是verify(bytes,bytes,bytes)的 ABI 函数选择器三参数偏移在 100 组向量中三个动态参数的偏移字段全部固定为0x6096、0x320800、0x6e01760。其中位于第二个数据区的长度字段固定为897与 EIP 规范中 Falcon-512 公钥的 897 字节完全一致说明布局与规范输入[pubkey][signature][message]相互印证消息递增文档明确说明“每个向量的大小增加 33 字节”对应消息数据随 Vector 序号逐步增长如 Vector 0 与 Vector 99 的总输入长度差异约 3 KB目的是让 Gas 成本随数据量变化从而拟合出“每 word 额外计费”的线性模型Expected 字段100 组向量全部标注Expected 0x…00。注意这与无效向量文件的标注值0x…01恰好相反两个文件的Expected字段语义各自独立接入测试框架时需以实现约定的返回值映射为准——EIP 正文中定义的成功返回值是…01、失败是…00而这两个向量文件中的Expected值分别与基准/失败场景绑定应按各自文件的注释与测试目标理解不要混用Gas与NoBenchmark基准向量集中每个元素都带Gas: 1、NoBenchmark: false两个字段供基准程序Go 基准测试读取后跳过/执行对应向量——NoBenchmark: false表示该向量应参与基准。一个基准向量的 ABI 解剖以 Vector 0 为例Input去掉选择器de8f50a1后的 payload 区可解码为已由脚本验证word 索引内容含义00x60第一个参数的偏移9610x320第二个参数的偏移80020x6e0第三个参数的偏移17603656第一个数据区的长度25897第二个数据区的长度 Falcon-512 公钥大小5533第三个数据区的长度Vector 0 的消息长度随向量递增这与 EIP 规范中[pubkey:897][signature:666][message]的尺寸设定吻合可作为校验向量完整性的快速手段。15 组无效数据测试向量不 revert 契约的分层验证invalid_signature_test_vectors.md 中内联了 15 组向量标题写明其用途是“验证一些无效签名情形”。每组记录的格式为{ Input: de8f50a1..., Expected: 0000000000000000000000000000000000000000000000000000000000000001, Name: vector N: 描述, }对全部 15 组Input的程序化解码结果如下它们共同构成了对预编译输入校验逻辑的系统性攻击面测试阶段一方法选择器之后的头帧缺陷Vector 0–1向量Name实际输入形态缺陷类型0No data after method signature仅de8f50a14 字节选择器后无任何参数数据1No enough data after method signaturede8f50a1abc5 字节选择器后只有 3 字节、不足一个 32 字节 word这两组验证即使 payload 完全缺失或只有残片预编译也必须正常返回而非 revert。阶段二三个偏移字段归零Vector 2–4向量Name被置零的偏移2Signature offset is zero第一个参数偏移0x60 → 0x003Public key offset is zero第二个参数偏移0xa0 → 0x004data offset is zero第三个参数偏移0xe0 → 0x00解码确认三组的长度区分别把0x60、0xa0、0xe0替换为0x00测试 ABI 动态偏移为零时的容错。阶段三签名区长度异常Vector 5–7向量Name签名区形态5signature length not present in input长度字段缺失payload 只有 100 字节不足以容纳长度字6signature length is present but its value is zero长度字段存在但为 07Signature indicated length is too long长度字段为0x600000000远超 666 字节上限阶段四公钥区长度异常Vector 8–10向量Name公钥区形态8public key length not present in input只有 32 字节占位数据0x11…11无长度字段9public key length is present but its value is zero长度字段为 010Public Key indicated length is too long长度字段为0x80000000000000远超 897 字节阶段五消息区长度异常Vector 11–13向量Name消息区形态11data length not present in input只有 32 字节占位数据0x22…22无长度字段12data length is present but its value is zero长度字段为 013Data indicated length is too long长度字段为0x5000000000000000Vector 8–13 的占位数据是0x1111…11/0x2222…22这种可辨识的填充模式便于在测试日志中快速定位是哪一段数据引发了路径分叉。阶段六格式正确但签名本身无效Vector 14Vector 14payload 约 1851 字节是 15 组中唯一携带真实 Falcon 材料的一组描述为“Correct format but invalid Signature”。解码显示它具备完整的三参数帧偏移0x60/0x312/0x6b3与对应的长度字段签名数据被替换为与公钥/消息不匹配的伪签名——它专门测试“数据形状完全合法但密码学验证失败”时预编译返回失败值而非 revert 的行为与 EIP 正文“invalid signatures will not cause the precompile to revert”的约定直接对应。统一断言全部不 revert15 组向量的Expected全部标注为…01结合 EIP 正文“数据格式错误、尺寸错误、无效签名均不导致 revert”的规范这组向量的预期行为是每一种畸形输入都应得到一次正常的、不 revert 的预编译调用。实现方接入时应按此语义编写断言调用成功、返回 32 字节、且无 out-of-gas 以外的异常而不是把Expected直接当作密码学验证结果。5 秒基准结果Gas 定价模型的实验来源benchmark_results.md 记录了在Intel(R) Core(TM) i7-10750H CPU 2.60GHzLinux/amd64go test 12 路并行上执行的 Go 基准测试pkg: github.com/ethereum/go-ethereum/core/vm BenchmarkPrecompiledEcrecover/-Gas3000-12 61453 91486 ns/op 3000 gas/op 32.79 mgas/s 800 B/op 7 allocs/op BenchmarkPrecompiledFalcon512/Vector_0-Gas2101-12 100734 56717 ns/op 2101 gas/op 37.04 mgas/s 2520 B/op 11 allocs/op BenchmarkPrecompiledFalcon512/Vector_1-Gas2106-12 101684 56510 ns/op 2106 gas/op 37.26 mgas/s 2520 B/op 11 allocs/op ... BenchmarkPrecompiledFalcon512/Vector_99-Gas2611-12 77630 72218 ns/op 2611 gas/op 36.15 mgas/s 5848 B/op 11 allocs/op可以从该结果中提取的关键信息对照基线以假定定价完全合理的ecRecover预编译3000 gas、约 91.5 µs/op为参照系每向量 Gas 递增Falcon512 基准从Vector_0 - Gas2101开始每个后续向量增加 5~6 gas如 2101 → 2106 → 2111 → … → 2611正好对应“每个 32 字节 word 追加计费”的模型性能区间Falcon512 单次验证约 56–83 µs/op吞吐约 29.9–38.6 mgas/s在测试机器上多数向量快于 ecRecover 的 91 µs内存特征B/op 从 2520 逐步增长到 5848allocs/op恒为 11说明分配次数与向量尺寸无关、分配总量随消息长度线性增长定价结论EIP 正文说明将 100 组BenchmarkPrecompiledFalcon512结果近似为关于输入字节数的线性方程后得到1465 gas 基础费用 每 word32 字节6 gas。该结论被直接写入 EIPS/eip-7619.md 的 Gas costs 小节。实战如何把这套资产用起来1. 功能测试无效输入矩阵对 15 组 invalid 向量逐一执行将十六进制Input解析为 calldata以Gas: 10之类极低 Gas 执行一次应得到out of gas对应 EIP 中 “empty input, too little gas” 的示例以充足 Gas 执行断言调用成功、未 revert、返回长度 32 字节、返回值与向量Expected相符对每组向量在断言信息中带上Name字段如vector 7: Signature indicated length is too long便于失败定位。2. 基准回归100 组有效向量将 bench_vectors.md 的 JSON 数组解析为测试用例列表按Name/Gas字段组织 Go benchmark命名风格可对齐BenchmarkPrecompiledFalcon512/Vector_N-Gas…对每个向量运行固定时长如 5 秒取样记录 ns/op、gas/op、mgas/s、B/op、allocs/op。3. 定价模型校验基准完成后把 100 组结果的 ns/op 或 gas/op 对输入字节数做线性回归斜率应接近“每 word 6 gas”、截距应接近 1465。若你的实现截距/斜率显著偏离说明底层 Falcon-512 实现EIP 正文注明其实现源自 PQClean 项目的常数开销或数据访问模式与提案预期不同需要复核。4. 与 Solidity 封装联调EIP 正文给出的包装函数verify(bytes,bytes,bytes)会校验success verifies.length 32并以verifies[31] 1作为布尔结果。测试时可以把无效向量喂给该封装预期调用不抛Invalid signature的require失败因为预编译不 revert而是返回false把基准向量喂给封装则返回true——这是两个文件Expected 分别为…00/…01在应用层的正确汇合点。小结EIP-7619 用三份相互配套的资产把“Falcon-512 预编译行为契约”变成了可机器验证的规格bench_vectors.md用 100 组源自官方 Falcon 测试向量的有效输入同时承担功能验证与 Gas 定价回归invalid_signature_test_vectors.md用 15 组分层构造的畸形输入缺失、截断、偏移归零、长度为零、长度超界、真材实料的伪签名锁定“不因数据错误 revert”这一关键语义benchmark_results.md则给出 1465 6 gas/word 定价模型的实验数据链。理解这三份文件就等于同时理解了 EIP-7619 的输入输出规范、容错边界与性能预算可以据此为新实现编写出一致、可复现的合规测试。【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考