Solana zwiększa rozmiar transakcji do 4 096 bajtów
Aktualizacja do Transaction v1 ma dać Solanie więcej miejsca na złożone płatności, multisigi i zero-knowledge proofs. Portfele i eksploratory muszą jednak dostosować swoje oprogramowanie, aby poprawnie odczytywać nowe transakcje.
Najważniejsze informacje
- Solana w środę zwiększa maksymalny rozmiar transakcji z 1 232 do 4 096 bajtów.
- Transaction v1 umożliwia bardziej złożone operacje w jednej transakcji, takie jak duże dowody i płatności wymagające wielu zatwierdzeń.
- Oprogramowanie odczytujące transakcje Solany musi rozpoznawać v1, aby uniknąć błędów i nieprawidłowego wyświetlania opłat.
Solana chce w środę zwiększyć maksymalny rozmiar transakcji z 1 232 bajtów do 4 096 bajtów. Dzięki temu sieć zyska ponad trzy razy więcej miejsca na transakcję, co da deweloperom większą swobodę przy bardziej złożonych operacjach wykonywanych za jednym razem.
Więcej miejsca na transakcję
W ramach nowego Transaction v1 zadania, które wcześniej trzeba było rozdzielać na kilka transakcji, częściej będzie można obsłużyć w ramach jednej operacji. Dotyczy to na przykład dużych dowodów kryptograficznych, płatności wymagających wielu zatwierdzeń oraz niektórych poufnych transferów.
Nowa forma działa już w sieciach testowych i deweloperskich Solany. Istniejące transakcje nadal będą działać bez zmian, więc portfele i aplikacje nie muszą od razu przechodzić na v1, jeśli nie potrzebują dodatkowego miejsca.
Ten krok usuwa stare ograniczenie, które Solana miała od dawna. Sieć była szybka i tania, ale transakcje były ograniczone sztywnym limitem 1 232 bajtów. Ethereum nie ma takiego stałego limitu protokołu i dlatego może obsługiwać większe, intensywnie wykorzystujące dane aplikacje w jednej transakcji, o ile użytkownik zapłaci wystarczającą opłatę.
Co musi zmienić oprogramowanie
Największy wpływ dotyczy nie tylko samej sieci, ale też oprogramowania, które odczytuje Solanę. Usługi pobierające bloki i transakcje muszą rozpoznawać v1. Jeśli tego nie zrobią, żądania mogą się nie powieść, gdy napotkają nową transakcję.
Zmienia się też miejsce, w którym dla niektórych systemów znajduje się informacja o priority fee. Priority fee to dodatkowa opłata, która ma przyspieszyć przetwarzanie transakcji. Starsze oprogramowanie może więc pokazywać opłatę równą zero, mimo że faktycznie została zapłacona.
Portfele, eksploratory i aplikacje tradingowe często pobierają informacje wyświetlane na ekranie właśnie z takich usług. Jeśli dane źródłowe są nieprawidłowe, użytkownik zobaczy to samo. Aktualizacja wymaga więc przede wszystkim technicznych zmian w tle, a nie obowiązkowego przejścia dla wszystkich.
Dlaczego to ważne
Dla europejskich użytkowników kryptowalut jest to istotne przede wszystkim dlatego, że większe transakcje dają więcej miejsca aplikacjom wykorzystującym dużo danych, takim jak zero-knowledge proofs i duże konstrukcje multisig. Limit 4 096 bajtów odpowiada też standardowej stronie pamięci sprzętu walidatorów, co pomaga utrzymać wydajne przetwarzanie. Zmiana jest więc szczególnie interesująca dla deweloperów i usług budowanych na Solanie, a nie tylko dla traderów śledzących kurs.
Zmiana jest niezależna od ostatnich głosowań dotyczących governance wokół SOL i podziału nowych tokenów. Zgodnie z dokumentacją aktualizacja jest częścią fazy Agave 4.2, która rozpoczyna się w tygodniu 17 sierpnia 2026 roku, ale przejście na v1 pozostaje opcjonalne dla istniejących aplikacji i portfeli.
