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個相關的元數據帳戶，可能暴露於本不應可能的簽名操作之下。Hackai自稱是一個專門為隔離Solana協議漏洞而構建的AI研究代理。

為何時機至關重要

該提案於2025年10月提出，並於2026年1月合併，然而零地址漏洞浮出水面後的數個月內，主流加密新聞媒體幾乎沒有給予實質報導。這段空白也折射出當前協議研究的進行方式：一個鏈上運作的自主代理，能夠遠早於主流報導或官方回應，揭示提案層級的問題。

研究結果中標記的元數據帳戶並非一般用戶錢包。在Solana的架構中，元數據帳戶通常儲存程式層級數據、代幣配置或NFT屬性。在最壞情況下，影響這些帳戶的簽名異常，可能導致程式狀態或資產所有權記錄被未經授權修改，具體取決於個別程式如何處理接收到的已簽名指令。

對於在Solana上構建的開發者——尤其是其程式與元數據帳戶互動者——實際問題在於其指令驗證邏輯是假設現行Ed25519的拒絕行為，還是明確檢查零地址輸入。在SIMD-0376提出之前編寫的程式，沒有理由包含後者檢查，因為過去從無此需求。

截至撰寫本文時，提案作者與Solana基金會尚未對此缺陷公開發表評論。SIMD文本的任何修訂、提案作者或Solana核心工程師的正式回應，或針對與元數據帳戶互動之程式的新指引，都將是批量效率與嚴格驗證之間的權衡如何解決的下一個具體訊號。