Solana实现交易签名验证现代化的努力遭遇了一个意外障碍，而障碍来自一个不同寻常的源头：一个以@hackhackai为别名、运行在Solana区块链上的自主AI研究代理。该代理发现了SIMD-0376提案中的一个潜在漏洞，该提案旨在改革网络处理交易签名验证的方式。

根据该代理的研究结果，这一漏洞——如果未得到解决——可能允许在零地址进行签名，而这种情况在现行规则下本不应发生，使433个元数据账户面临风险。

SIMD-0376的实际内容

Solana目前使用ed25519-dalek库验证Ed25519签名。SIMD-0376提议将其替换为ZIP-215 cofactored EdDSA验证标准，这是同一底层密码学曲线的另一种实现——该标准最初源自一项Zcash改进提案。

签名验证运行在网络处理的每一笔交易上，这正是该层面的效率提升会在Solana全部吞吐量上产生叠加效应的原因。这一更换的实际收益是切实可见的：该提案旨在实现批量签名处理，在处理大量签名时，可将验证器的计算成本降低约40%。

Syndica的David Rubin于2025年10月6日提出该提案。经过后续完善，该提案于2026年1月28日合并至Solana Improvement Documents代码库。

零地址问题

该漏洞的核心在于ZIP-215标准引入的一个特定边界情况：以零地址签名或为零地址签名的可能性。按照正常的Ed25519规则，此类签名会被直接拒绝。而在ZIP-215更为宽松的验证逻辑下，则未必如此。

零地址并非普通的边界情况。它相当于一个空标识——一个全零地址，实际上不存在对应的私钥——这正是现行规则将任何针对它的签名视为表面无效的原因，也是一个可验证的零地址签名会动摇Solana这类基于账户系统的基本假设的原因。

这种宽松性实际上是刻意为之。ZIP-215的设计初衷是接受更广泛的合法签名表示形式，从而使批量处理更加直接。代价是它也放宽了某些此前作为隐性安全防线的边界检查。

根据@hackhackai的研究结果，其结果是Solana生态系统中关联的433个元数据账户可能暴露于本不应存在的签名操作之下。Hackhackai自称是一个专注于AI的研究代理，专门用于发现Solana协议中的漏洞。

时机为何重要

该提案于5年10月提出，并于2026年1月合并，然而在之后的数月里，零地址漏洞的披露并未获得主流加密新闻媒体的实质性报道。这一空白也折射出当前协议研究的演进方式：一个在链上运行的自主代理，可以在主流报道或官方回应之前，率先揭示提案层面的问题。

研究结果中标记的元数据账户并非普通的用户钱包。在Solana的架构中，元数据账户通常存储程序级数据、代币配置或NFT属性。在最坏的情况下，影响这些账户的签名异常可能使程序状态或资产所有权记录遭到未经授权的修改，具体取决于各个程序如何处理传入的已签名指令。

对于在Solana上构建的开发者——尤其是那些程序与元数据账户交互的开发者——实际的问题在于，其指令验证逻辑是假定现行的Ed25519拒绝行为，还是显式检查零地址输入。在SIMD-0376提出之前编写的程序没有任何理由包含后一种检查，因为此前从未有过这种需要。

截至本文撰写时，提案作者和Solana基金会均未就该漏洞公开置评。SIMD文本的任何修订、提案作者或Solana核心工程师的正式回应，或针对与元数据账户交互的程序的新指引，都将是这一批量效率与严格验证之间权衡如何解决的下一个具体信号。