AktualnościKryptoSolana uruchomiła Transaction V1 w testnecie, łącząc wieloetapowe operacje w jedną transakcję atomową

Solana uruchomiła Transaction V1 w testnecie, łącząc wieloetapowe operacje w jedną transakcję atomową

Autor: Cryptopolitan·

Najważniejsze informacje

  • •Transaction V1 zwiększa maksymalny rozmiar serializowanej transakcji Solany z 1 232 bajtów do 4 096 bajtów, czyli o 3,3-krotność; po raz pierwszy aktywowano ją w testnecie w epoce 1025 1 września, a uruchomienie w sieci głównej zaplanowano na 9 września.
  • •Większy rozmiar transakcji umożliwia przetwarzanie dowodów wiedzy zerowej, dużych transakcji multisig i schematów podpisów takich jak BLS w jednej atomicznej transakcji, co zmniejsza liczbę transakcji i koszty podpisów.
  • •Ulepszenie napędzają propozycje SIMD-0296 i SIMD-0385: pierwsza podnosi limit bajtów, druga definiuje format komunikatu V1 i przenosi konfigurację transakcji do samego komunikatu.
  • •V1 usuwa Address Lookup Tables i umieszcza adresy inline, jednak limit Solany wynoszący 64 różne konta na transakcję pozostaje bez zmian.
  • •Anza wymaga od dostawców RPC przejścia na Agave v4.2.2 lub v4.3.0-beta.3, ponieważ niezgodni konsumenci RPC mogą napotkać błędy wywołań, takie jak getBlock, gdy w grę wchodzą transakcje V1.
Solana uruchomiła Transaction V1 w testnecie, łącząc wieloetapowe operacje w jedną transakcję atomową

Anza włączyła Transaction V1 w testnecie Solany 1 września, dając sieci możliwość ostatniego testu ulepszenia przed planowanym uruchomieniem w sieci głównej 9 września. Zgodnie z informacjami Solana Compass zmiana ta pozwala na przetwarzanie obciążeń kryptograficznych i DeFi, które wcześniej musiały być dzielone między wiele transakcji, w pojedynczej atomicznej transakcji.

Podzielone zadania mieszczą się teraz w jednym wywołaniu

Najbardziej widoczną zmianą jest zwiększenie przestrzeni. Maksymalny rozmiar serializowanej transakcji Solany wzrósł z 1 232 bajtów do 4 096 bajtów — czyli o 3,3-krotność — co weszło w życie w epoce 1025 testnetu. Limit 1 232 bajtów sięgał najwcześniejszego projektu protokołu Solany, a V1 oznacza pierwsze podniesienie tego limitu na poziomie formatu komunikatu od czasu, gdy V0 wprowadziło Address Lookup Tables jako częściowe obejście presji rozmiarowej.

Zgodnie ze stroną poświęconą dużym transakcjom Solana Foundation większy rozmiar umożliwia implementację dowodów wiedzy zerowej, dużych transakcji multisig oraz różnych schematów podpisów, które wcześniej nie mieściły się w jednej transakcji. Rezultatem jest mniejsza liczba transakcji do przetworzenia, niższe koszty podpisów oraz brak konieczności czekania na łańcuch potwierdzeń. Na ulepszeniu skorzystają schematy podpisów BLS, transakcje poufne oraz konfiguracje multisig.

Kluczowe dla ulepszenia są dwie propozycje: SIMD-0296 podnosi limit rozmiaru transakcji z 1 232 do 4 096 bajtów, natomiast SIMD-0385 definiuje format komunikatu V1 i przenosi konfigurację transakcji do samego komunikatu.

W niecałą dobę po aktywacji dyrektor generalny Anzy Brennan Watt opublikował wpis na X, wskazując dużą transakcję w eksploratorze testnetu, z wiadomością: "ATTENTION: large transactions have hit the testnet."

Dlaczego jedna transakcja wygrywa z bundlem

Atomowość ma znaczenie, ponieważ deweloperzy czasami obchodzili stary limit rozmiaru Solany za pomocą bundli Jito. SIMD-0296 wprost opisuje to obejście i zauważa, że bundle nie posiadają atomowości na poziomie protokołu, w przeciwieństwie do pojedynczej natywnej transakcji.

Zgodnie z dokumentacją Jito bundle może zawierać do pięciu transakcji przetwarzanych sekwencyjnie w trybie wszystko-albo-nic. Bundle działają jednak w silniku blokowym Jito i konkurują między sobą o napiwki dla walidatorów. Transakcja V1 to natomiast pojedyncza natywna transakcja Solany, objęta gwarancją atomowości na poziomie transakcji zapewnianą przez Solanę.

Dla deweloperów DeFi upraszcza to budowanie tras swapów, dowodów i innych operacji wieloetapowych: jeśli cała operacja mieści się w transakcji V1, kończy się sukcesem albo jest wycofywana jako jedna natywna transakcja, zamiast opierać się na bundlu transakcji.

Co DeFi zyskuje poza dodatkowymi bajtami

V1 zmienia także samą strukturę transakcji. Podczas gdy transakcje Legacy i V0 obsługują opłaty priorytetowe i żądania zasobów poprzez instrukcje ComputeBudget, SIMD-0385 przenosi te ustawienia do konfiguracji transakcji V1, ułatwiając walidatorom rozpoznanie zapotrzebowania na zasoby bez przeszukiwania listy instrukcji.

V1 dodatkowo usuwa Address Lookup Tables (ALT), których V0 używało do skracania adresów kont. Zgodnie z analizą Fundacji dotyczącą kompromisu ALT w V1 V1 umieszcza adresy w sposób inline, co upraszcza dane wejściowe walidatorów w porównaniu z podejściem V0, które zużywało więcej bajtów przy konwersji adresów w aplikacjach intensywnie korzystających z kont.

Praktyczną korzyścią dla routerów i agregatorów DEX jest większa przestrzeń na złożone trasy atomowe. Ulepszenie nie jest jednak pozbawione ograniczeń: limit Solany wynoszący 64 różne konta na transakcję pozostaje bez zmian, więc aplikacje intensywnie korzystające z kont nadal mogą natrafić na ten sufit, mimo że pojemność bajtowa nie stanowi już ograniczenia.

Ulepszenie pojawia się w momencie, gdy Solana coraz mocniej wchodzi w finanse on-chain. Raport Galaxy dotyczący Solany za II kwartał 2026 pokazuje rosnącą aktywność w obszarze stablecoinów, tokenizowanych akcji i aktywów rzeczywistych. Zdaniem Galaxy przyszły potencjał Solany będzie w dużej mierze zależał od możliwości wykorzystania tych aktywów w pożyczkach, jako zabezpieczenia, w handlu z dźwignią i generowaniu dochodu — a nie tylko w emisji czy handlu. Dane DeFiLlama dotyczące Solany wskazują na silną obecność DeFi na tej platformie.

Timing zbiega się również z fazą ulepszenia Agave 4.2. Jak wcześniej informował Cryptopolitan, plan stopniowej redukcji kosztów miał przynieść oszczędności rzędu 90% i skrócić czas przetwarzania z 500 do 200 milisekund, co przyniesie korzyści emitentom stablecoinów, dostawcom portfeli i systemom płatności.

Operatorzy RPC mają tydzień na aktualizację

V1 jest opcjonalne, więc transakcje Legacy i V0 nadal działają. Otwartym pytaniem pozostaje gotowość infrastruktury odczytującej ruch V1.

Anza wymagała od dostawców RPC przejścia na Agave v4.2.2 lub v4.3.0-beta.3. Checklista migracji Helius Agave 4.2 ostrzega, że konsumenci RPC, którzy nie zadeklarują zgodności z V1, mogą napotkać błędy wywołań, takie jak getBlock, gdy w grę wchodzi transakcja V1.

Wdrożenie rozpoczęło się od lokalnych testów V1 24 sierpnia, po czym 29 sierpnia potwierdzono datę uruchomienia w sieci głównej — 9 września. V1 włączono w testnecie 1 września w epoce 1025, a aktywacja w sieci głównej zaplanowana jest na 9 września.

Najnowszy test w testnecie stanowi ostatni krok przygotowawczy dla dostawców RPC, indekserów, portfeli, SDK i platform analitycznych przed uruchomieniem w sieci głównej.