Zcash może przyspieszyć. Deweloperzy proponują bloki co 20 sekund

Zcash może wkrótce skrócić docelowy czas między blokami z 25 do 20 sekund. Propozycja przygotowana przez przedstawicieli ekosystemu zakłada dalsze przyspieszenie potwierdzania transakcji i poprawę wygody korzystania z sieci.

Jej autorzy chcą, aby rozwiązanie trafiło pod najbliższe głosowanie społeczności i zostało rozważone w ramach planowanej aktualizacji NU7.1. Przekonują, że najnowsze testy obciążeniowe wskazują na akceptowalny poziom ryzyka związanego z powstawaniem osieroconych bloków.

Projekt jest kontynuacją zmian wprowadzonych przez ZIP 218. Aktualizacja NU7 skróciła docelowy czas generowania bloków z 75 do 25 sekund. Opisywaliśmy tę zmianę w tym artykule, zwracając uwagę również na inne konsekwencje wdrożenia nowej wersji protokołu. Teraz deweloperzy chcą wykonać kolejny krok.

Zcash chce skrócić czas oczekiwania na potwierdzenie transakcji

Propozycję przedstawili ValarDragon i Evan Forbes na forum społeczności Zcash. Argumentują oni, że krótszy czas między blokami poprawi komfort użytkowników dokonujących płatności, korzystających z giełd oraz rozwiązań do wymiany międzyłańcuchowej, takich jak NEAR Intents.

W przypadku płatności sprzedawca lub pośrednik często musi poczekać na pierwsze potwierdzenie transakcji, zanim podejmie kolejne działanie. Skrócenie docelowego czasu bloku powinno ograniczyć to opóźnienie. Nie oznacza to jednak, że każda transakcja będzie potwierdzana dokładnie po 20 sekundach. W sieci Proof of Work rzeczywisty czas wydobycia kolejnego bloku jest zmienny, a proponowana wartość określa średni docelowy odstęp między blokami.

Zmiana ma być również uzupełnieniem rozwijanego mechanizmu Crosslink, a nie rozwiązaniem zależnym od jego wdrożenia. Szybsze bloki warstwy bazowej mają ograniczać opóźnienia niezależnie od tego, czy dodatkowy mechanizm finalności zostanie uruchomiony.

Projekt propozycji ZIP, zgłoszony jako pull request nr 1437 na GitHubie, przewiduje jednak nie tylko zmianę czasu bloków. Deweloperzy chcą dostosować również wybrane parametry protokołu, tak aby zachować dotychczasowe założenia dotyczące emisji monet, obciążenia portfeli i działania sieci.

Testy wskazują na akceptowalny poziom ryzyka

Najważniejszym zagrożeniem związanym z częstszym generowaniem bloków jest wzrost liczby bloków osieroconych. Dochodzi do tego, gdy różni górnicy niemal jednocześnie wydobędą konkurencyjne bloki, a część sieci nie zdąży jeszcze odebrać i zweryfikować wcześniejszego bloku. W rezultacie jeden z konkurencyjnych bloków nie trafia do ostatecznego łańcucha.

Autorzy propozycji przeprowadzili testy w środowisku obejmującym 80 górników rozmieszczonych w 12 regionach świata. W eksperymencie wykorzystano pełne bloki o rozmiarze 2 MB i docelowy odstęp wynoszący 20 sekund. Scenariusz zakładał maksymalne obciążenie protokołu Ironwood, a następnie wykorzystanie transakcji transparentnych. W sieci złożonej wyłącznie z węzłów Zakura odnotowano 1,9 proc. osieroconych bloków. Przy równym podziale między Zakura a Zebra-Andele wskaźnik wyniósł 3,3 proc.

Dla porównania wcześniejsza analiza przygotowana na potrzeby skrócenia czasu bloków do 25 sekund wykazała 4,86 proc. osieroconych bloków w eksperymencie empirycznym oraz 3,26 proc. w modelu teoretycznym. Wyniki opisano w analizie opublikowanej w maju przez zespół Zebra. Według autorów nowa propozycja spełnia więc wcześniejsze kryteria bezpieczeństwa przyjęte dla 25-sekundowych bloków. Zastrzegają oni jednak, że testy przeprowadzono w sztucznie rozproszonym środowisku. Ich zdaniem rzeczywista sieć główna może osiągać lepsze wyniki ze względu na geograficzne skupienie części mocy obliczeniowej i pul wydobywczych. Wartości z testów nie są zatem prognozą dokładnego poziomu osieroconych bloków w sieci głównej.

Limity prywatnych transakcji pozostaną bez zmian w skali dobowej

Istotnym elementem propozycji jest zachowanie dotychczasowego obciążenia portfeli obsługujących transakcje chronione. Gdyby limity działań shielded pozostały na obecnym poziomie, częstsze bloki zwiększyłyby maksymalne dobowe obciążenie związane z synchronizacją lekkich portfeli o 25 proc.

Dlatego autorzy chcą obniżyć limity przypadające na pojedynczy blok o jedną piątą. Globalny budżet shielded oraz limity działań Orchard i Ironwood miałyby spaść z 330 do 264. W przypadku Sapling limit wejść i wyjść zostałby zmniejszony z 300 do 240. Maksymalny rozmiar bloku pozostałby na poziomie 2 MB. Takie rozwiązanie ma utrzymać dotychczasowe dobowe ograniczenia obciążenia portfeli, zamiast zwiększać przepustowość prywatnych transakcji.

Projekt przewiduje też dostosowanie parametrów ekonomicznych i technicznych. Nagroda za pojedynczy blok miałaby zostać zmniejszona do 80 proc. dotychczasowej wartości, a interwał halvingu wydłużony z 5 040 000 do 6 300 000 bloków. Zachowany zostałby tym samym dotychczasowy harmonogram emisji w przeliczeniu na czas. Dostosowaniu uległaby również stopa ponownej emisji w ramach Network Sustainability Mechanism (NSM).

Okno uśredniania trudności wzrosłoby ze 102 do 128 bloków, co pozwoliłoby zachować zbliżony czas analizy wynoszący około 2550–2560 sekund. Domyślny termin wygaśnięcia transakcji zostałby wydłużony ze 120 do 150 bloków. Zalecana głębokość anchorów pozostałaby na poziomie trzech bloków, co przy nowym docelowym odstępie oznaczałoby skrócenie odpowiadającego jej czasu z 75 do 60 sekund.

Propozycja może trafić pod głosowanie społeczności

Na razie jest to projekt, a nie zatwierdzona zmiana protokołu. ValarDragon i Evan Forbes chcą zgłosić go do najbliższego głosowania społeczności i rozważyć w ramach NU7.1. W dyskusji na forum ValarDragon opowiedział się za uwzględnieniem skrócenia czasu bloków w nadchodzącym procesie konsultacji.

Opublikowany harmonogram konsultacji i głosowania przewiduje przedstawienie projektów pytań 9 listopada, dyskusję do 15 listopada oraz głosowanie w dniach 16–30 listopada. Trzeba jednak zaznaczyć, że zaplanowane głosowanie dotyczy przede wszystkim przyszłości udziału Zcash Community Grants w funduszu deweloperskim. Nie ma jeszcze potwierdzenia, że propozycja dotycząca 20-sekundowych bloków zostanie formalnie włączona do zestawu pytań.

Sam projekt ZIP pozostaje otwarty na GitHubie i wymaga jeszcze dopracowania niektórych kwestii technicznych, między innymi związanych z harmonogramem strumieni finansowania i mechanizmem ponownej emisji w Network Sustainability Mechanism. 8 listopada autorzy oznaczyli propozycję jako gotową do przeglądu, ale nie oznacza to jej zatwierdzenia. Ostateczna decyzja o wdrożeniu będzie więc zależała od dalszych prac, wyników konsultacji i poparcia społeczności.

Przeczytaj również:
Chiny uderzają w Solanę. Nie chodzi już tylko o handel kryptowalutami
Elizabeth Warren może przejąć kontrolę nad Senacką Komisją Bankową. Trump i branża krypto znajdą się na celowniku