Większy limit działa w nowym formacie
Solana udostępnia format transakcji v1 z limitem 4096 bajtów. Oficjalna dokumentacja sprawdzona 15 września wskazuje, że rozwiązanie jest aktywne w sieci głównej oraz środowiskach testowych. Dotychczasowe formaty legacy i v0 mają limit 1232 bajtów. Zwiększenie pojemności dotyczy ilości danych mieszczących się w pojedynczej operacji. Dokumentacja zwraca jednocześnie uwagę na odczyt nowych transakcji: aplikacje, które nie zadeklarują obsługi v1, mogą nie potrafić ich poprawnie pobrać. Zmiana wymaga więc uwagi także od dostawców narzędzi i portfeli.
Więcej miejsca dla podpisów i dowodów
Uzasadnienie propozycji zwiększenia rozmiaru wskazuje konkretne ograniczenia zgłaszane przez programistów. Chodzi między innymi o rozbudowane podpisy, firmowe portfele wymagające wielu zatwierdzeń oraz dowody kryptograficzne używane w rozwiązaniach chroniących poufność. Te dane muszą zmieścić się w treści wysyłanej do sieci. Wcześniejszy limit wymuszał dodatkowe rozwiązania organizujące większą operację. Autorzy dokumentu opisują większą transakcję jako sposób na obsłużenie zastosowań, które wcześniej napotykały barierę rozmiaru, a nie jako zmianę wartości przesyłanych środków.
Przebudowano także strukturę wiadomości
Dokument opisujący v1 przedstawia nowy układ danych transakcji. Parametry określające dostępne zasoby przeniesiono do konfiguracji wiadomości, zamiast przekazywać je wyłącznie w osobnych instrukcjach. Format rezygnuje również z tablic wyszukiwania adresów, stosowanych w v0. Adresy potrzebne do wykonania operacji są umieszczane bezpośrednio w wiadomości. Celem opisanej konstrukcji jest uproszczenie przyjmowania i przetwarzania transakcji przez oprogramowanie sieci. Dla twórców aplikacji przejście na v1 oznacza zmianę sposobu przygotowania danych, nie tylko podniesienie jednej liczby w ustawieniach.
Jedna operacja nadal zachowuje spójność
Podstawowa zasada wykonania transakcji Solany pozostaje istotna przy łączeniu kilku czynności. Transakcja może obejmować wiele instrukcji, ale sieć rozlicza ich wykonanie razem. Jeżeli któraś instrukcja zakończy się niepowodzeniem, zmiany stanu z całej transakcji są cofane. Oficjalny opis rozróżnia jednak cofnięcie zmian i naliczenie kosztu: nieudane wykonanie nie oznacza automatycznie braku opłaty. W wiadomości znajdują się też podpisy uprawnionych kont oraz identyfikator niedawnego bloku. Większa przestrzeń na dane nie usuwa tych elementów ani potrzeby autoryzacji operacji.
Opłaty mają własne zasady
Dokumentacja opłat opisuje koszt podstawowy oraz opcjonalną opłatę priorytetową. Pierwszy składnik jest związany z podpisami, drugi służy zwiększeniu priorytetu obsługi transakcji. Użytkownik płaci w SOL, a odpowiedzialne za opłatę konto musi dysponować środkami wymaganymi przez sieć. Dlatego informacja o większym limicie danych nie jest cennikiem konkretnej operacji. Opłata i dostępna przestrzeń to odrębne parametry, które aplikacja musi poprawnie obsłużyć. W oficjalnym opisie podkreślono również, że opłaty mogą być pobrane przy nieudanym wykonaniu, co ma znaczenie przy ponawianiu operacji.
Sieć nadal sprawdza poprawność transakcji
Dokumentacja procesu przetwarzania opisuje kolejne kontrole wykonywane przez walidatorów: sprawdzenie podpisów, struktury danych, wieku transakcji, budżetu zasobów i konta pokrywającego opłatę. Dopiero potem następuje ładowanie kont oraz wykonanie instrukcji. Przy v1 większe wiadomości mogą być przesyłane w kilku fragmentach protokołu QUIC. Nie oznacza to pominięcia pozostałych kontroli. Nieprawidłowy podpis, brak środków na koszt operacji albo niewystarczający budżet nadal mogą zatrzymać przetwarzanie. To rozróżnienie wyjaśnia, dlaczego sama obsługa większego pliku danych nie przesądza o powodzeniu każdej transakcji.
INTERPRETACJA HOSTuvo
Dla HOSTuvo jest to wiadomość o możliwościach infrastruktury. Ocenę wykorzystania nowego formatu trzeba oddzielić od krótkoterminowego zachowania kursu SOL. Samo wdrożenie nie uzasadnia sygnału kupna.