Solana przygotowuje się do zwiększenia limitu transakcji v1 do 4096 bajtów

Solana (SOL) przygotowuje aktualizację formatu transakcji v1, która zwiększy maksymalny rozmiar pojedynczej transakcji z 1232 bajtów do 4096 bajtów. To techniczne zmiany, które pozwolą na pomieszczenie transakcji o około 3,3 razy większych niż dotychczasowy limit w jednej operacji.

Fundacja Solana sklasyfikowała tę zmianę w oficjalnym dokumencie aktualizacyjnym jako 'Większe rozmiary transakcji' w sekcji 'Oczekujące aktywacje funkcji'. Zmiana ta opiera się na SIMD-0296 i SIMD-0385, a oficjalny pulpit aktualizacji wskazuje, że Agave 4.2 ma być wydane w sierpniu 2026 roku, pozostawiając funkcję zwiększenia rozmiaru transakcji w stanie oczekiwania na aktywację.

Kluczowym elementem tej aktualizacji jest limit transakcji. Dotychczasowy limit rozmiaru transakcji Solany wynosił 1232 bajty, a dokument SIMD-0296 wyjaśnia, że limit ten wynika z projektu IPv6 MTU 1280 bajtów. Po odjęciu nagłówków pozostaje struktura, w której rzeczywisty ładunek transakcji wynosi 1232 bajty.

Solana zauważa, że po wprowadzeniu QUIC stworzono środowisko umożliwiające wysyłanie większych transakcji, dlatego nowy limit wynosi 4096 bajtów. Zmiana struktury przesyłania w sieci prowadzi do dostosowania limitu transakcji, który wcześniej był dostosowany do ograniczeń rozmiaru pakietów.

Format v1 nie zastępuje istniejącego v0 ani transakcji legacy. Aplikacje, portfele i indeksatory, które chcą korzystać z większych rozmiarów transakcji, muszą dostosować się do nowego formatu. Dokumentacja RPC Solany wskazuje, że aby odbierać wiadomości v1, należy ustawić maxSupportedTransactionVersion: 1 w żądaniu.

W wiadomościach v1 zawarte są obliczenia limitów oraz ograniczenia rozmiaru danych, a także obiekt transactionConfig zawierający computeUnitLimit, loadedAccountsDataSizeLimit i priorityFee. To różni się od dotychczasowego sposobu składania żądań zasobów jako oddzielnych instrukcji.

Struktura techniczna również ulega zmianie. SIMD-0385 wyjaśnia, że transakcje v1 używają bajtu wersji 129 i zamiast dotychczasowych instrukcji ComputeBudgetProgram umieszczają żądania zasobów w masce ustawień w nagłówku transakcji. Tabela wyszukiwania adresów (ALT) nie jest wspierana.

Tabela wyszukiwania adresów zmniejsza przestrzeń, odwołując się do zewnętrznej tabeli, zamiast bezpośrednio umieszczać wszystkie adresy w transakcji. V1 zakłada, że w ramach limitu 4096 bajtów często można bezpośrednio umieścić listę adresów. Jednak w przypadku obciążeń o wysokiej zależności od ALT, efekt zwiększenia limitu może być ograniczony.

Ta zmiana poszerza możliwości pojedynczych transakcji atomowych dla deweloperów. Fundacja Solana wyjaśniła, że dowody zerowej wiedzy, duże transakcje wielo-podpisowe, operacje wsadowe i niektóre struktury podpisów on-chain były trudne do pomieszczenia w ramach dotychczasowego limitu 1232 bajtów. Transakcje atomowe to struktury, w których wiele operacji udaje się lub nie udaje razem.

W przypadku złożonych operacji DeFi lub przetwarzania wielo-podpisów instytucjonalnych można zmniejszyć obciążenie związane z dzieleniem transakcji na wiele części. Solana zauważa, że mimo wzrostu tygodniowych transakcji, zyski z opłat, aktywność deweloperów i popyt na tokeny powinny być analizowane jako osobne wskaźniki, co sugeruje, że wskaźniki przetwarzania sieci powinny być rozważane w kontekście zmian infrastrukturalnych.

Jednak v1 nie eliminuje wszystkich wąskich gardeł. Oficjalne wyjaśnienie Solany wskazuje, że v1 zapewnia strukturę, która pozwala weryfikatorom i zespołom klientów na wcześniejsze odczyty opłat i żądań zasobów. Z drugiej strony, z perspektywy deweloperów aplikacji, ograniczenie do 64 kont może nadal stanowić przeszkodę.

W dyskusjach deweloperów pojawiły się zarówno oczekiwania, jak i obawy. W dyskusji na GitHubie zasugerowano, że większy rozmiar transakcji byłby przydatny w przypadku złożonych swapów, jednego kliknięcia DeFi i atomowych likwidacji. Z drugiej strony, podkreślono, że wydajność sieci, podział pakietów, przepustowość weryfikatorów i projekt opłat są ważniejsze.

W lokalnym środowisku weryfikacyjnym otwarte są możliwości testowe. Repozytorium przykładów Solany informuje, że funkcja enable_tx_v1 w solana-test-validator jest już aktywna. Z drugiej strony, kod uruchomieniowy odrzuca transakcje v1 jako UnsupportedVersion, jeśli funkcja jest wyłączona, co wymaga sprawdzenia, czy aktywacja jest włączona w klastrze.

Crypto Briefing donosi, że transakcje v1 mogą trafić do testnetu w ciągu kilku tygodni. Jednak w oficjalnej dokumentacji Solany status wciąż jest w oczekiwaniu na aktywację. Zastosowanie w mainnecie i harmonogram powinny być potwierdzone w kontekście aktywacji funkcji.

Ta aktualizacja jest bardziej związana ze zmianami w infrastrukturze deweloperskiej niż z prognozami cenowymi. Portfele, RPC, indeksatory i narzędzia deweloperskie muszą sprawdzić, czy obsługują analizę transakcji v1 i transactionConfig. Dotychczasowe transakcje v0 i legacy będą nadal działać, ale usługi, które chcą korzystać z transakcji 4096 bajtów, muszą wspierać nowy format.

Niniejsza treść ma charakter wyłącznie informacyjny i nie stanowi porady finansowej, inwestycyjnej, prawnej ani podatkowej. Wszelkie wydarzenia, nagrody, promocje online lub powiązane informacje, o których tu mowa, nie powinny być traktowane jako rekomendacja, zachęta ani zaproszenie do kupna, sprzedaży, wymiany lub innego rodzaju obrotu aktywami kryptograficznymi. Aktywa kryptograficzne charakteryzują się dużą zmiennością i mogą prowadzić do strat. Dostępność usług, produktów i powiązanych wydarzeń WEEX może się różnić w zależności od regionu. Użytkownik jest odpowiedzialny za upewnienie się, że jego udział jest zgodny z obowiązującymi lokalnymi przepisami i regulacjami.