Solana aktywowała funkcję txv1 w sieci głównej około 01:00 UTC 15 września, na początku epoki 1035. Aktualizacja zwiększa maksymalny rozmiar transakcji z 1 232 bajtów do 4 096 bajtów, zapewniając ponad trzykrotnie większą pojemność niż wcześniej.

Dodatkowa przestrzeń jest dostępna za pośrednictwem formatu transakcji V1. Aplikacje muszą jawnie dodać jego obsługę przed rozpoczęciem korzystania z niego, podczas gdy transakcje legacy i V0 pozostają w pełni obsługiwane w ramach dotychczasowych limitów.

Większa transakcja nie oznacza większego transferu SOL

Nowy limit dotyczy ilości informacji przenoszonych przez transakcję, a nie ilości SOL, którą użytkownik może wysłać. Standardowy transfer zazwyczaj wymaga niewielkiej ilości danych, ponieważ obejmuje tylko małą liczbę kont, instrukcji i podpisów.

Bardziej zaawansowane operacje mogą wymagać kilku instrukcji, licznych adresów kont, wielu zatwierdzeń lub dowodów kryptograficznych. Gdy te informacje przekraczały wcześniejszy limit, deweloperzy musieli ograniczać ładunek danych, dzielić operację na wiele transakcji lub korzystać z alternatyw, takich jak tabele wyszukiwania adresów i pakiety transakcji.

Solana może przetwarzać niezależne transakcje równolegle, jak opisano w tym przewodniku po działaniu Solany. V1 nie zmienia tego modelu wykonywania. Zapewnia natomiast dodatkową przestrzeń, gdy pojedyncza operacja musi zawierać kilka powiązanych elementów.

Gdy takie instrukcje są przesyłane jako jedna transakcja atomowa, są przetwarzane jako całość. Cała operacja kończy się powodzeniem albo jej zmiany zostają wycofane, co zapobiega sytuacji, w której tylko część instrukcji trafia do rejestru.

Operacje, które mogą skorzystać z dodatkowej przestrzeni

• Transakcje pakietowe: Aplikacja tradingowa może umieścić powiązane instrukcje w jednej transakcji zamiast koordynować kilka potwierdzeń.
• Duże zatwierdzenia multisig: Portfele skarbowe i firmowe mogą pomieścić więcej podpisów oraz informacji o kontach, gdy operacja wymaga udziału wielu osób.
• Dowody zerowej wiedzy: Aplikacje mogą dowodzić spełnienia określonego warunku bez ujawniania wszystkich informacji leżących u jego podstaw, ale sam dowód może wymagać znacznej przestrzeni w transakcji.
• Schematy podpisów on-chain: Niektóre kryptograficzne formaty podpisów generowały wcześniej więcej danych, niż mogła pomieścić pojedyncza transakcja Solany.

Solana Foundation wskazuje poufne transfery, zagnieżdżone multisigi, operacje pakietowe i niektóre schematy podpisów on-chain jako potencjalne zastosowania nowego formatu.

Większość użytkowników portfeli nie musi podejmować działań

Aktywacja nie wymaga od użytkowników przenoszenia SOL, tworzenia kolejnego adresu ani konwertowania istniejącego konta. Aplikacje, które nadal korzystają z transakcji legacy lub V0, powinny działać tak jak przed aktualizacją.

Użytkownicy będą potrzebować kompatybilnego portfela, gdy aplikacja zdecyduje się wysłać transakcję V1. Aktualizowanie oprogramowania portfela zapewni dostęp do tej obsługi w miarę jej wprowadzania przez dostawców, ale aplikacje nadal powinny sprawdzać kompatybilność przed poproszeniem portfela o podpis.

Dla użytkowników zmiana może z czasem oznaczać mniejszą liczbę próśb o zatwierdzenie w przypadku złożonych operacji. Usługa, która wcześniej wymagała kilku powiązanych transakcji, może zamiast tego wyświetlić jedno żądanie i oczekiwać jednego potwierdzenia.

Deweloperzy i indeksatory muszą zaktualizować oprogramowanie

Wysyłanie transakcji V1 jest opcjonalne, ale ich odczytywanie może powodować problemy z kompatybilnością infrastruktury, która nie została zaktualizowana.

Usługi RPC pobierające transakcje lub bloki muszą ustawić maxSupportedTransactionVersion: 1. Bez tego ustawienia żądanie dotyczące transakcji V1 może zwrócić błąd. Pojedyncza nieobsługiwana transakcja może również spowodować niepowodzenie żądania dotyczącego całego bloku.

Indeksatory są narażone na inne ryzyko. V1 przechowuje limit obliczeniowy, limit danych załadowanych kont i opłatę priorytetową wewnątrz transactionConfig, a nie w instrukcjach Compute Budget. Oprogramowanie, które nadal skanuje poprzednią lokalizację, może nieprawidłowo sklasyfikować transakcję albo wykazać jej limity zasobów i opłatę priorytetową jako zero.

Aplikacje tworzące transakcje V1 muszą jawnie ustawić limity jednostek obliczeniowych i danych załadowanych kont. W nowym formacie obie wartości domyślnie wynoszą zero, więc ich pominięcie może spowodować niepowodzenie transakcji przed rozpoczęciem wykonywania.

Transakcje większe niż 1 232 bajty muszą być również przesyłane z użyciem kodowania base64. Ścieżka przesyłania base58 zachowuje wcześniejszy limit rozmiaru.

V1 zwiększa przestrzeń, ale zmienia inne limity

V1 nie jest po prostu formatem V0 z większym ładunkiem danych. Może zawierać bezpośrednio w transakcji do 64 adresów kont, ale nie obsługuje tabel wyszukiwania adresów. Duplikaty adresów kont są również odrzucane.

Zasady te tworzą dla zespołów aplikacyjnych inny wybór projektowy. V0 pozostaje użyteczny, gdy tabele wyszukiwania zapewniają efektywny sposób odwoływania się do kont, podczas gdy V1 jest przeznaczony dla operacji, które bardziej korzystają z dodatkowej przestrzeni na instrukcje, podpisy lub dowody.

Podstawowa płatność prawdopodobnie nie odniesie żadnych korzyści z nowego formatu. V1 lepiej sprawdza się w aplikacjach, które mogą zastąpić skomplikowaną sekwencję lub pomieścić dane, które wcześniej nie mieściły się w jednej transakcji.

Większe transakcje mogą wiązać się z wyższymi opłatami

Zwiększenie limitu bajtów nie sprawia automatycznie, że każda transakcja V1 staje się droższa. Koszt zależy od żądanych zasobów, liczby podpisów i opłaty priorytetowej wybranej przez aplikację.

Większe komunikaty zużywają jednak więcej przepustowości walidatorów. Dokumentacja Solany wskazuje, że harmonogram może wymagać wyższej opłaty priorytetowej dla większej transakcji niż dla mniejszej transakcji ubiegającej się o taki sam priorytet, szczególnie gdy przestrzeń bloków jest poszukiwana.

V1 wyraża opłatę priorytetową jako całkowitą kwotę w lamportach. V0 używa ceny za jednostkę obliczeniową, co oznacza, że platformy analityczne muszą znormalizować oba formaty przed ich porównaniem.

Popyt na opłaty priorytetowe może znacznie się zmieniać wraz z aktywnością sieci, jak pokazują najnowsze dane dotyczące opłat Solany. Deweloperzy będą więc musieli zestawić wygodę jednej większej operacji z kosztem jej uwzględnienia w okresach przeciążenia.

Aktywacja rozpoczyna test przyjęcia formatu

Aktualizacja usuwa ograniczenie, które wcześniej wpływało na sposób budowania aplikacji Solany, ale aktywacja w sieci głównej nie gwarantuje powszechnego wykorzystania. Portfele, dostawcy RPC, indeksatory i biblioteki aplikacyjne muszą prawidłowo obsługiwać nowy format, zanim deweloperzy będą mogli polegać na nim w produktach kierowanych do użytkowników.

Najwcześniejsze korzyści mogą pojawić się w zastosowaniach, które już wcześniej miały problemy z dotychczasowym limitem, w tym przy poufnych transferach, instytucjonalnych układach multisig i aplikacjach wymagających dużej liczby instrukcji. W przypadku zwykłych transferów ustalone formaty pozostają prostszą opcją.

Znaczenie V1 będzie zależeć od tego, czy umieszczenie tych zastosowań w jednej transakcji atomowej przyniesie wystarczające oszczędności w zakresie koordynacji, podpisów i nieudanych prób, aby uzasadnić wymagane aktualizacje infrastruktury.

Ten artykuł ma wyłącznie charakter informacyjny i nie stanowi porady finansowej ani inwestycyjnej. Kompatybilność portfeli, obsługa aplikacji i opłaty transakcyjne mogą ulec zmianie.

Źródło: Coindoo