Sprawdzenie kompatybilności przed przejściem na transakcje Solana v1 o rozmiarze 4096 bajtów

Nowy format transakcji v1 Solana (SOL) przeszedł kontrolę kompatybilności infrastruktury przed aktywacją na głównym łańcuchu. Zmiana polega na zwiększeniu maksymalnego rozmiaru pojedynczej transakcji z 1232 bajtów do 4096 bajtów, jednak kluczowym zagadnieniem jest to, czy RPC, indeksery, gRPC i sponsorzy opłat będą w stanie prawidłowo odczytać nowy format, a nie problemy z konsensusem łańcucha.

Fundacja Solana ogłosiła na stronie aktualizacji sieci, że Agave 4.2 zostało uruchomione na głównym łańcuchu, ale funkcja 'Larger Transaction Sizes' jest w stanie oczekiwania na aktywację do 4 września 2026 roku. Ta sama funkcja ma na celu zwiększenie istniejącego limitu transakcji o około 3,3 razy poprzez nowy format transakcji v1.

Ta zmiana nie jest tylko prostym zwiększeniem rozmiaru. SIMD-0296 i SIMD-0385 przedstawiają zastosowania takie jak duże multi-sig, dowody zerowej wiedzy (ZK proof) oraz przesyłanie wsadowe. W v1 zmniejsza się zależność od tabeli adresów używanej w istniejących transakcjach, a informacje o opłatach i ograniczeniach zasobów przenoszone są do oddzielnej wartości konfiguracyjnej transactionConfig.

Sposób odczytu w istniejącym systemie może stanowić problem w tym punkcie. Jeśli indeksery i sponsorzy opłat tylko przeszukają instrukcję ComputeBudget, aby obliczyć opłaty lub limity jednostek obliczeniowych, mogą przegapić limit opłat transakcji v1 lub odczytać go jako 0. Przykładowe repozytorium fundacji Solana wyjaśnia, że wiadomości v1 zawierają TransactionConfig zamiast instrukcji ComputeBudget.

Dokumentacja RPC Solana informuje, że należy wprowadzić maxSupportedTransactionVersion: 1 w wywołaniach getTransaction, getBlock i blockSubscribe. Pominięcie tej wartości lub ustawienie jej na 0 może spowodować błąd w getTransaction, gdy przyjdzie transakcja v1, a getBlock może nie być w stanie odczytać całego bloku.

Subskrypcje WebSocket również nie są wyjątkiem. blockSubscribe może zwrócić block: null, jeśli ustawienia nie są zgodne. Dokumentacja deweloperska Solana zaleca traktowanie tego jako błąd, a nie pusty blok. Transakcje v1 są identyfikowane przez pierwszy bajt 129, czyli 0x81.

W ścieżkach gRPC i Geyser mogą wystąpić cichsze błędy. Dokumentacja deweloperska Solana ostrzega, że gRPC nie ma wartości opt-in, takich jak maxSupportedTransactionVersion, a starsze stuby protobuf mogą zignorować pole Message.config. W takim przypadku system nie zatrzyma się, ale może traktować transakcje v1 jak v0 i pominąć ustawienia opłat.

Przykładowe repozytorium fundacji Solana sugeruje minimalne wersje, takie jak @solana/kit 8.0.0, yellowstone-grpc-proto 12.6.0, yellowstone-grpc geyser 15.1.1. Oferowane są również oddzielne przykłady dotyczące odczytu, przesyłania, indeksowania bloków oraz gRPC.

Weryfikacja narzędzi rdzeniowych również trwa. Problem zgłoszony w solana-sdk issue #831 przez anza-xyz dotyczy tego, że maksymalny rozmiar v1 4096 bajtów nie jest prawidłowo wymuszany w deserializatorze i sanitarze. Jednak strona statusu Solana pokazuje, że na dzień 4 września 2026 roku działają węzły RPC Mainnet Beta, a nie zgłoszono żadnych incydentów.

Ta sprawa ma silny charakter kontroli kompatybilności infrastruktury związanej z rozszerzeniem limitu transakcji Solana v1. Jeśli wcześniejsze zagadnienia dotyczyły limitu 4096 bajtów i aktywacji funkcji w zależności od klastra, to teraz kluczowe jest, czy systemy zaplecza będą w stanie odczytać nową strukturę, gdy rzeczywiste transakcje v1 będą miały miejsce.

Strona aktualizacji Solana wskazuje, że funkcja 'Larger Transaction Sizes' jest w stanie oczekiwania na aktywację do 4 września 2026 roku. Ten termin jest bardziej techniczną mapą drogową, którą portfele, RPC, indeksery i narzędzia deweloperskie muszą przygotować sekwencyjnie, niż pojedynczym wydarzeniem, które zmienia strukturę przetwarzania Solana.

Technicznie rzecz biorąc, transakcje v1 nie zastępują istniejących v0 i transakcji legacy. Istniejący format nadal działa, ale aplikacje korzystające z większych rozmiarów transakcji i transactionConfig muszą wspierać nowy format. W przypadku aktualizacji infrastruktury blockchain, nie tylko zasady konsensusu, ale także kompatybilność systemów zewnętrznych do odczytu i przechowywania danych wpływa na rzeczywiste ryzyko operacyjne.

Sponsorzy opłat i indeksery mogą być szczególnie narażeni. Jeśli źle odczytają górny limit opłat lub limity jednostek obliczeniowych, usługi ponoszące koszty w imieniu użytkowników mogą być narażone na nieprzewidziane struktury kosztów, a systemy analizy transakcji mogą błędnie rejestrować ustawienia zasobów transakcji v1. To nie jest awaria, która zatrzymuje łańcuch, ale obszar, który wymaga dodatkowej kontroli przez operatorów usług.

Krajowe giełdy lub dostawcy portfeli, którzy prowadzą wpłaty i wypłaty Solana oraz monitorowanie on-chain, również nie są wolni od tych problemów. Muszą upewnić się, że ścieżki odczytu bloków, transakcji, indeksowania, monitorowania ryzyka i obliczania opłat obsługują strukturę wiadomości v1. Szczególnie w przypadku korzystania z zewnętrznych dostawców węzłów lub danych opartych na Geyser, konieczne jest sprawdzenie reprodukowalności protobuf i wersji biblioteki.

Do momentu, gdy transakcje Solana v1 rzeczywiście wejdą w życie, kluczowe punkty kontrolne to: △ ustawienie opcji wywołania RPC maxSupportedTransactionVersion: 1 △ odzwierciedlenie ścieżki przechowywania transactionConfig △ regeneracja stubów protobuf gRPC △ rozpoznanie prefiksu wersji 0x81. Na stronie aktualizacji Solana funkcja 'Larger Transaction Sizes' jest w stanie oczekiwania na aktywację do 4 września 2026 roku.