Co dokładnie się zmienia?
Solana skraca docelowy czas produkcji bloku (slot time) na mainnecie z 400 milisekund do 350 milisekund. Zgodnie z relacją CryptoSlate zmiana ta aktywowała się na początku epoki 1019, ale ze względu na tak zwane opóźnienie jednoepokowe (one-epoch delay) sieć zachowuje dotychczasowe parametry, a nowy cel 350 ms faktycznie zacznie obowiązywać dopiero od epoki 1020.
Dla uściślenia pojęć: slot time to docelowy interwał, w którym powinien zostać wyprodukowany jeden blok. Epoka to dłuższe okno czasowe złożone z wielu slotów, po którym stosuje się niektóre zmiany parametrów. Compute units (jednostki obliczeniowe) to miara tego, ile obliczeń może zawierać blok.
Dlaczego jednocześnie obniża się limit obliczeń na blok?
To sedno całej historii. Zgodnie z CryptoSlate bloki otrzymują krótszy docelowy interwał produkcji, ale nie dostają większego dopuszczalnego wolumenu obliczeń na sekundę. W praktyce oznacza to, że gdy bloki produkowane są częściej, każdy pojedynczy blok musi być "lżejszy", aby całkowite obciążenie sieci i walidatorów w jednostce czasu pozostawało mniej więcej stałe.
Logika jest prosta: samo przyspieszenie bloków bez korekty limitu obliczeń oznaczałoby więcej obliczeń na sekundę, co mogłoby obciążyć walidatory i zagrozić stabilności sieci. Obniżenie limitu na blok jest więc zabezpieczeniem, a nie efektem ubocznym.
Jak daleko są w tym sieci testowe?
Zgodnie z CryptoSlate rollout w innych miejscach jest bardziej zaawansowany niż na mainnecie:
| Sieć | Stan docelowego czasu bloku |
|---|---|
| Mainnet | przejście z 400 ms na 350 ms (faktycznie od epoki 1020) |
| Testnet | efektywny cel 200 ms |
| Devnet | cel 300 ms, aktywowana bramka 250 ms, ale na razie nieskuteczna |
Testnet i Devnet służą więc jako etap wstępny, na którym bardziej agresywne wartości testowane są wcześniej, zanim trafią na mainnet.
Skąd pochodzi ta zmiana?
CryptoSlate odwołuje się do changelogu Solany z 6 sierpnia, gdzie te parametry są opisane. Stopniowe skracanie czasu bloku jest częścią szerszego, długoterminowego dążenia Solany do niższej latencji sieci.
Co na razie nie jest jasne?
Z dostępnego źródła nie wynika dokładna data w kalendarzu, kiedy nastąpi epoka 1020, ani konkretna wartość liczbowa, o ile dokładnie obniża się limit obliczeń na blok. Z tego źródła nie jest też udokumentowane, jaki realny wpływ będzie miała zmiana na latencję transakcji, opłaty czy stabilność sieci dla użytkowników końcowych. To okaże się dopiero po zachowaniu mainnetu po epoce 1020.
Na co zwracać uwagę przy tego typu zmianach?
Przy modyfikacjach parametrów blockchaina na poziomie protokołu warto śledzić trzy rzeczy: czy zmiana rzeczywiście aktywuje się w ogłoszonej epoce, czy nie dojdzie do nieplanowanych awarii lub spowolnienia produkcji bloków oraz czy przepustowość (liczba transakcji na sekundę) realnie się zmienia, czy pozostaje stabilna. Właśnie dlatego, że Solana celowo utrzymuje tu obliczenia na sekundę na stałym poziomie, główną metryką do zweryfikowania jest raczej latencja i stabilność niż surowa przepustowość.
charliedesk odnotowuje tę zmianę, aby móc ją później porównać z tym, co rzeczywiście stanie się w sieci po epoce 1020.