Wiceprezes ds. technologii Fundacji Solana, Jacob Creech, przedstawił 30 sierpnia kilka nadchodzących aktualizacji Solany. Transakcja V1 jest zaplanowana na 9 września, a pierwszy etap redukcji opłat sieciowych ma nastąpić w tygodniu rozpoczynającym się 31 sierpnia.
Podsumowanie
- Solana planuje aktywację Transakcji V1 9 września, zwiększając rozmiar transakcji do 4096 bajtów.
- Pierwszy etap redukcji opłat rozpocznie się w przyszłym tygodniu, rozpoczynając pięcioetapową ścieżkę do 90% oszczędności.
- Solana już skróciła docelowe sloty do 350 milisekund, a później planowane są 300, 250 i 200.
- Alpenglow pozostaje zaplanowane na październik, a Solana dąży do około 150-milisekundowej finalizacji po aktywacji mainnetu.
- Transakcje starsze i w wersji zero pozostają kompatybilne, ponieważ deweloperzy muszą zdecydować się na większy format V1.
Creech powiedział również, że deweloperzy planują dalsze skracanie czasu slotów i celują w październik dla Alpenglow. Jednak te zmiany następują w ramach oddzielnych procesów aktywacji. Transakcja V1 nie spowoduje automatycznie skrócenia czasu slotów ani aktywacji Alpenglow.
Transakcja V1 podnosi limit Solany do 4096 bajtów
Transakcja V1 podniesie maksymalny rozmiar serializowanej transakcji Solany z 1232 bajtów do 4096 bajtów. Wzrost jest około 3,3 razy większy niż istniejący limit, zgodnie z oficjalną mapą drogową aktualizacji Solany oficjalną mapą drogową aktualizacji.
Większy format może obsługiwać transakcje zawierające dowody wiedzy zerowej, złożone instrukcje wielopodpisowe i inne operacje wymagające dużej ilości danych. Powiązana propozycja SIMD-0296 identyfikuje również podpisy BLS i operacje międzyłańcuchowe jako możliwe zastosowania.
Deweloperzy muszą zdecydować się na format V1. Istniejące transakcje starsze i w wersji zero pozostaną ważne. Transakcja V1 nie będzie obsługiwać tabel odnośników adresów, co oznacza, że aplikacje muszą zdecydować, który format jest odpowiedni dla każdej transakcji.
Zmiana wymaga również, aby portfele, interfejsy programowania aplikacji i inna infrastruktura obsługiwały większe ładunki danych. Propozycja uznaje możliwe ryzyko przepustowości i fragmentacji sieci, co sprawia, że skoordynowane testowanie jest ważne przed szerszym przyjęciem.
Redukcja opłat Solany rozpoczyna się od jednego z pięciu kroków
Pierwsza redukcja opłat nie przynosi od razu pełnego celu 90%. Solana planuje pięć etapów, które ostatecznie obniżą obliczanie opłat z 6960 lamportów na bajt do 696 lamportów na bajt.
Solana używa sald zwolnionych z opłat, aby ograniczyć niekontrolowany wzrost stanu. Aplikacje blokują SOL podczas tworzenia kont przechowujących dane. Ten SOL jest zazwyczaj zwracany po zamknięciu konta, co oznacza, że opłaty działają bardziej jak zwrotny depozyt niż powtarzająca się opłata sieciowa.
Niższe wymagania zmniejszą ilość SOL, którą deweloperzy muszą zablokować podczas tworzenia kont tokenów, kont programów i innych stanów onchain. Może to obniżyć koszty wejścia dla aplikacji zarządzających wieloma kontami użytkowników.
Agave 4.2 zawierał niezbędny kod, ale Solana umieściła zmiany za niezależnymi bramkami funkcji. Jak wcześniej informowało crypto.news, walidatorzy mogą aktywować oddzielnie aktualizacje opłat, rozmiaru transakcji i czasu slotów po testach.
Szybsze sloty Solany przebiegają według oddzielnego harmonogramu
Solana już zmniejszyła docelowy czas slotu do 350 milisekund, w porównaniu z poprzednim celem 400 milisekund. Sieć planuje dodatkowe etapy przy 300, 250 i ostatecznie 200 milisekund.
Creech nie podał dat dla tych pozostałych etapów. Każda redukcja wymaga osobnej aktywacji funkcji. Deweloperzy sieci mogą zatem monitorować wydajność walidatorów przed przejściem do kolejnego celu.
Krótsze sloty mogą poprawić szybkość potwierdzania transakcji i zwiększyć częstotliwość, z jaką walidatorzy tworzą bloki. Stawiają również większe wymagania dotyczące synchronizacji czasu i sieci dla walidatorów. Solana planuje proporcjonalnie dostosować limity zasobów podczas wdrażania.
Transaction V1 i skrócone czasy slotów są związane z szerszą mapą drogową wydajności Solany, ale pozostają technicznie odrębne. Raporty opisujące 9 września jako datę obu zmian byłyby przesadą w stosunku do ogłoszenia Creecha.
Alpenglow pozostaje celem na październik
Alpenglow to proponowana przez Solanę przebudowa konsensusu. Solana twierdzi, że ma na celu skrócenie finalizacji transakcji do około 150 milisekund, w porównaniu z dłuższym procesem potwierdzania stosowanym przez obecny system konsensusu.
Oficjalna mapa drogowa wymienia Alpenglow jako "w trakcie rozwoju", podczas gdy Agave 4.3 jest spodziewane w październiku. Wpis Creecha potwierdza październik jako obecny cel, ale żadne z tych oświadczeń nie potwierdza gwarantowanej daty aktywacji w sieci głównej.
Przed tym terminem Solana ma rozpocząć pierwszy etap redukcji czynszu i aktywować Transaction V1 9 września. Dalsze redukcje slotów będą zależeć od osobnych aktywacji walidatorów. Alpenglow musi również ukończyć testy i zapewnić wymagane wsparcie sieci.
W momencie publikacji nie zaobserwowano żadnych zweryfikowanych ruchów rynkowych bezpośrednio związanych z ogłoszeniem Creecha.
