Próba modernizacji weryfikacji podpisów transakcji w Solanie napotkała niespodziewaną przeszkodę — i przyszła ona z nietypowego źródła: autonomicznego agenta badawczego AI działającego pod aliasem @hackhackai w blockchainie Solana. Agent zidentyfikował potencjalną podatność w SIMD-0376, propozycji mającej zreformować sposób, w jaki sieć obsługuje weryfikację podpisów transakcji.

Według ustaleń agenta luka — jeśli nie zostanie załatwiona — mogłaby umożliwić podpisywanie pod adresem zerowym, scenariusz, który przy obecnych zasadach powinien być niemożliwy, co wystawia na ryzyko 433 konta metadanych.

Co proponuje SIMD-0376

Solana obecnie weryfikuje podpisy Ed25519 przy użyciu biblioteki ed25519-dalek. SIMD-0376 miałby ją zastąpić standardem weryfikacji ZIP-215 cofactored EdDSA — inną implementacją tej samej krzywej kryptograficznej — standardem, który powstał jako propozycja ulepszenia Zcash.

Weryfikacja podpisów przebiega przy każdej transakcji przetwarzanej przez sieć, dlatego zyski wydajności na tej warstwie kumulują się w całej przepustowości Solany. Praktyczna korzyść ze zmiany jest wymierana: propozycja ma umożliwić wsadowe przetwarzanie podpisów, co mogłoby obniżyć koszty obliczeniowe walidatorów o około 40% przy obsłudze dużych wolumenów podpisów.

David Rubin z Syndiki przedstawił propozycję 6 października 2025 roku. Po późniejszym udoskonaleniu została ona scalona z repozytorium Solana Improvement Documents 28 stycznia 2026 roku.

Problem adresu zerowego

Podatność dotyc konkretnego przypadku brzegowego wprowadzonego przez standard ZIP-215: możliwości podpisania z adresem zerowym lub dla niego. Według normalnych zasad Ed25519 taki podpis zostałby odrzucony. Przy bardziej pobłażliwej logice weryfikacji ZIP-215 może nie zostać.

Adres zerowy to nie byle jaki przypadek brzegowy. Pełni funkcję tożsamości zerowej — adresu składającego się z samych zer, dla którego w praktyce nie istnieje klucz prywatny — dlatego obecne zasady traktują każdy podpis wobec niego jako z założenia nieważny, a weryfikowalny podpis pod adresem zerowym podważyłby podstawowe założenie systemów opartych na kontach, takich jak Solana.

Ta pobłażliwość jest zamierzona. ZIP-215 zaprojektowano tak, aby akceptował szerszy zakres poprawnych reprezentacji podpisów, co upraszcza przetwarzanie wsadowe. Kosztem jest złagodzenie pewnych kontroli brzegowych, które wcześniej pełniły rolę niejawnych zabezpieczeń.

W efekcie, według ustaleń @hackhackai, 433 konta metadanych powiązane z ekosystemem Solany mogłoby być narażone na operacje podpisywania, które nigdy nie powinny być możliwe. Hackhackai określa się jako agent badawczy skoncentrowany na AI, stworzony specjalnie do wyłapywania podatności w protokołach Solany.

Dlaczego timing ma znaczenie

Propozycję przedstawiono w październiku 2025 roku, a scalono w styczniu 2026 roku, jednak luka z adresem zerowym wyszła na jaw bez znaczącego omówienia w głównych serwisach informacyjnych o kryptowalutach w kolejnych miesiącach. Ta luka jest także przekrojem tego, jak dziś wygląda badanie protokołów: autonomiczny agent działający on-chain może ujawnić problem na poziomie propozycji znacznie wcześniej niż media główne czy oficjalne odpowiedzi.

Konta metadanych wskazane w ustaleniach nie są zwykłymi portfelami użytkowników. W architekturze Solany konta metadanych zazwyczaj przechowują dane na poziomie programu, konfiguracje tokenów lub atrybuty NFT. W najgorszym razie anomalia podpisu dotykająca tych kont mogłaby umożliwić nieautoryzowane modyfikacje stanu programu lub zapisów własności aktywów — w zależności od tego, jak poszczególne programy obsługują przychodzące podpisane instrukcje.

Dla deweloperów budujących na Solanie — zwłaszcza tych, których programy wchodzą w interakcję z kontami metadanych — praktyczne pytanie brzmi, czy ich logika walidacji instrukcji zakłada obecne zachowanie odrzucania Ed25519, czy też jawnie sprawdza dane wejściowe z adresem zerowym. Programy napisane przed przedstawieniem SIMD-0376 nie miały powodu zawierać tego drugiego sprawdzenia, ponieważ nigdy nie było potrzebne.

Na moment pisania tego tekstu ani autorzy propozycji, ani Solana Foundation nie odnieśli się publicznie do l. Jakakolwiek rewizja tekstu SIMD, formalna odpowiedź autorów lub inżynierów rdzenia Solany czy nowe wytyczne dla programów współpracujących z kontami metadanych byłyby kolejnymi konkretnymi sygnałami, jak ten kompromis między wydajnością wsadową a ścisłą weryfikacją zostanie rozwiązany.