Solana planuje na 9 września wdrożenie Transaction v1, nowego formatu, który zwiększa maksymalny rozmiar serializowanej transakcji z 1 232 bajtów do 4 096 bajtów.
Podsumowanie
- Solana planuje zwiększyć maksymalny rozmiar transakcji z 1 232 bajtów do 4 096 bajtów w środę na mainnecie.
- Transaction v1 pozostaje opcjonalny, podczas gdy formaty legacy i v0 działają nadal w ramach istniejących limitów rozmiaru.
- Aplikacje odczytujące bloki muszą obsługiwać wersję pierwszą lub ryzykować błędy w przypadku napotkania nowego formatu.
- V1 usuwa tabele odnośników adresów i przechowuje limity zasobów bezpośrednio w metadanych konfiguracji każdej transakcji.
- Oficjalna mapa drogowa Solany oznacza aktywację mainnetu jako oczekującą, więc termin 9 września może się jeszcze zmienić.
Zwiększenie to daje programistom około 3,3 razy więcej miejsca na transakcje. Oficjalna mapa drogowa Solany mówi, że dodatkowa pojemność może pomieścić dowody wiedzy zerowej, duże operacje wielopodpisowe, partie oraz niektóre schematy podpisów onchain.
Duże operacje wcześniej musiały być dzielone na kilka transakcji, gdy ich instrukcje, podpisy i informacje o kontach przekraczały limit 1 232 bajtów. Proces ten dodawał złożoności, ponieważ jedna transakcja mogła się powieść, a inny krok mógł się nie udać.
Transaction v1 może pozwolić programistom połączyć więcej tych instrukcji w jedną operację atomową. Albo każda instrukcja się powiedzie, albo cała transakcja kończy się niepowodzeniem. Model ten może przynieść korzyści trasom handlowym, poufnym transferom, operacjom międzyłańcuchowym i aplikacjom przetwarzającym złożone dowody kryptograficzne.
Aktualizacja nie podnosi limitu Solany wynoszącego 64 odwołane konta na transakcję. Aplikacje mogą zawierać więcej danych i instrukcji, ale nie mogą automatycznie wchodzić w interakcje z większą liczbą kont.
Istniejące transakcje Solany pozostaną ważne
Transaction v1 jest opcjonalny. Portfele i aplikacje mogą nadal wysyłać transakcje legacy i v0 w ramach istniejącego limitu 1 232 bajtów. Użytkownicy nie muszą migrować tokenów, wymieniać SOL ani wypełniać roszczenia przed aktywacją.
Programiści muszą świadomie przyjąć nowy format, aby uzyskać dostęp do jego większej pojemności. Dokumentacja Solany identyfikuje trzy obsługiwane formaty: legacy, v0 i v1. Każdy format inaczej organizuje adresy kont i limity zasobów.
Format v0 używa tabel odnośników adresów (ALT), aby reprezentować adresy kont za pomocą skompresowanych indeksów jednobajtowych. V1 usuwa ALT i umieszcza pełne 32-bajtowe adresy kont bezpośrednio w transakcji.
Tworzy to kompromis. V1 zapewnia większą ogólną obwiednię, ale aplikacje, które w dużym stopniu polegają na tabelach odnośników, mogą zużywać więcej bajtów na reprezentację tych samych kont. Analiza techniczna Solany wykazała, że 90% próbkowanych transakcji dodałoby mniej niż 1 400 bajtów po konwersji z v0 do v1.
Dostawcy infrastruktury muszą zaktualizować swoje oprogramowanie
Główne ryzyko zgodności dotyczy usług, które odczytują bloki i transakcje. Dostawcy wywołań zdalnych procedur muszą ustawić maksymalną obsługiwaną wersję transakcji na jeden. W przeciwnym razie żądania mogą zakończyć się niepowodzeniem, gdy napotkają transakcję v1.
Indeksatory, eksploratory i usługi analityczne muszą również zmienić sposób pobierania limitów zasobów. Transakcje legacy i v0 umieszczają limity obliczeniowe i ustawienia opłat priorytetowych w instrukcjach ComputeBudget. V1 przechowuje je w dedykowanej konfiguracji transakcji.
Przestarzałe usługi mogą zatem wyświetlać nieprawidłowe informacje. Na przykład eksplorator może pokazywać zerową opłatę priorytetową, nawet jeśli użytkownik ją uiścił. Sponsorzy opłat i aplikacje, które sprawdzają limity transakcji, muszą odczytywać nową konfigurację, a nie skanować stare instrukcje.
Aplikacje wysyłające transakcje v1 muszą jawnie ustawić limity jednostek obliczeniowych i danych ładowanych, ponieważ oba domyślnie wynoszą zero. Deweloperzy powinni przetestować konstrukcję transakcji, podpisywanie i dekodowanie przed przeniesieniem ruchu produkcyjnego do tego formatu.
9 września pozostaje docelową datą aktywacji
Wiceprezes ds. technologii Fundacji Solana, Jacob Creech, wskazał 9 września jako planowaną datę dla sieci głównej. Jak wcześniej poinformowało crypto.news, aktualizacja jest zawarta w wydaniu Agave 4.2 firmy Anza.
Jednak oficjalna mapa drogowa nadal oznacza funkcję sieci głównej jako „nieaktywowaną”. Mówi również, że harmonogram wydań Anzy jest „wstępny i może ulec zmianie”. Testnet i devnet już aktywowały tę funkcję, zgodnie z najnowszą stroną statusu Fundacji.
Zwiększenie rozmiaru wynika z SIMD-0296, podczas gdy SIMD-0385 definiuje format v1. Jacob Creech i Andrew Fitzgerald są współautorami obu propozycji.
Limit 4096 bajtów został wybrany częściowo dlatego, że cztery kilobajty odpowiadają typowemu rozmiarowi strony pamięci używanej przez sprzęt walidatorów. Większe transakcje będą również zużywać dodatkowe pasmo, chociaż aktualizacja nie wprowadza osobnej opłaty za bajt.
Transakcja v1 pozostaje oddzielona od obniżek czynszów Solany, krótszych celów slotów i przeprojektowania konsensusu Alpenglow. W powiązanych doniesieniach crypto.news poinformowało, że Alpenglow celuje w około 150-milisekundową finalność, a październik pozostaje celem rozwojowym, a nie gwarantowaną datą aktywacji.
