BIP152 – Kompaktowe bloki od Bitcoin Core

Jako że zwiększenie maksymalnej wielkości bloku jest nieuniknione, równolegle trwają prace nad zwiększeniem szybkości przekazywania nowych bloków oraz nad ograniczeniem ilości przesyłanych danych przy przekazywaniu nowego bloku.

 

 

Jako że zwiększenie maksymalnej wielkości bloku jest nieuniknione, równolegle trwają prace nad zwiększeniem szybkości przekazywania nowych bloków oraz nad ograniczeniem ilości przesyłanych danych przy przekazywaniu nowego bloku.

 

Obecny mechanizm transmisji P2P działa następująco: węzeł który otrzymał blok, sprawdza go w całości (czy spełnia aktualne warunki, czy transakcje są prawidłowe itd.) i informuje podłączone węzły że ma nowszy blok. Jeżeli któryś z podłączonych węzłów odpowie, że nie ma takiego bloku wysyłany jest do niego blok w całości.

 

Ponieważ węzły które pracują już jakiś czas (są zsynchronizowane z siecią i odbierają transakcje na bieżąco) zazwyczaj mają w swojej pamięci lwią część transakcji jakie są dołączane do nowego bloku, przesyłanie kompletnej informacji nie jest potrzebne. Jednym z proponowanych sposobów zmniejszenia ilości przesyłanych danych jest właśnie BIP0152 (Compact Block Relay [CBR]) który zakłada dwa różne tryby informowania o nowym bloku.

 

W pierwszym trybie, informacja o nowym bloku przekazywana jest do kolejnych węzłów dopiero po kompletnej weryfikacji bloku (tak jak dotychczas). Drugi tryb umożliwia przekazywanie informacji już po wstępnej weryfikacji nagłówka i listy transakcji zawartych w bloku.

 

Drugi tryb daje szybszą propagację informacji o nowym bloku w sieci, dzięki czemu kopalnie mogą szybciej reagować i generować mniej „osieroconych” bloków. Niesie to jednak ze sobą pewne niebezpieczeństwo, bo atakujący może generować nieprawidłowe bloki które będą rozgłaszane w sieci i odrzucane dopiero po pełnej weryfikacji – w „zwykłym” trybie taki blok nie jest przekazywany a węzeł który go nam dostarczył jest banowany.

 

W trybie opisanym w BIP152 węzeł początkowo przekazuje tylko nagłówek, skrócone hasze zawartych w bloku transakcji oraz transakcje, które uznaje za nieznane węzłowi któremu wysyła dane. Taką „nieznaną” transakcją jest zawsze transakcja wydobycia bloku (coinbase).

 

Na podstawie otrzymanej informacji węzeł otrzymujący próbuje rekonstruować blok, i w przypadku braku transakcji wysyła zapytanie o nie do węzła przekazującego. Po uzyskaniu wszystkich brakujących transakcji węzeł może samodzielnie zbudować i zweryfikować nowy blok.

 

Aby zawrzeć niezbędne informacje dla typowego 1MB bloku zawierającego 2500 transakcji trzeba przesłać w pierwszym komunikacie około 15kb informacji. Testy wykazują, że przy dołączeniu 6 „nietypowych” transakcji zawartych w bloku w 86% przypadków węzeł otrzymujący ma kompletną informację niezbędną do zbudowania bloku natychmiast po otrzymaniu pierwszego komunikatu. W przypadku dołączania tylko transakcji generacji udaje się tak przesłać około 50% bloków.

 

Oczywiście, jeżeli węzeł otrzymujący nie posiada większej ilości transakcji bardziej opłacalne może okazać się przesłanie kompletnego bloku, i taki wyjątek jest możliwy.

 

Kolejnym rozwinięciem protokołu CBR będzie dołączenie transmisji UDP w miejsce TCP, co umożliwi jeszcze szybsze wysyłanie bloków. Jako że transport UDP nie czeka na informację zwrotną o poprawnym odbiorze, a nie wszystkie pakiety UDP trafiają do adresata po kolei (a czasem są „gubione” przez sieć) transport taki będzie musiał zawierać dodatkowe sumy kontrolne i informacje nadmiarowe umożliwiające odtworzenie brakujących ramek informacji. Nie jest to szczególnie trudne, UDP z powodzeniem stosowane jest np. w protokole Torrent oraz strumieniowaniu audio/video.

 

Prace nad szybszym sposobem przekazywania bloków były już prowadzone w 2013 roku, jednak próby wykorzystania filtrów Blooma (BIP037) do określania i przesyłania brakujących transakcji okazały się być bardzo zasobożerne i nie dawały spodziewanych efektów przyspieszenia propagacji.

 

Bardzo podobnym do tego rozwiązaniem, jest Xthin proponowane przez Bitcoin Unlimited. Tu do przekazania informacji o transakcjach zawartych w bloku oraz o brakujących są wykorzystywane właśnie filtry Blooma. Wyniki testów są optymistyczne, 95% 1MB bloków udaje się przekazać w mniej niż 80kb informacji, średnio jest to nieco ponad 41kb. Nie widać jednak nic, co sugerowałoby przeniesienie tego rozwiązania do Core. Nie ma też informacji jak taki sposób przekazywania informacji zwiększa zapotrzebowanie węzła na moc obliczeniową czy pamięć.

 

Zmiana sposobu przesłania bloków jest kluczowa dla rozwoju sieci Bitcoin. Samo zwiększanie bloku nie jest optymalne. Przedtem lepiej jest dane “skompresować” tak, aby sieć mogła ich pomieścić więcej dzięki czemu oszczędza się zasoby.

 

Jako że spora część mocy obliczeniowej czuwającej nad bezpieczeństwem sieci znajduje się za Wielkim Chińskim Firewallem, przy zwiększeniu wielkości bloku i utrzymaniu dotychczasowego protokołu jego przesyłania może dochodzić do zatykania się komunikacji pomiędzy częścią sieci w Chinach i resztą świata. Oczywiście, może to prowadzić do zwiększenia ilości bloków osieroconych a tym samym spadek bezpieczeństwa (trzeba będzie czekać więcej potwierdzeń żeby mieć pewność) oraz spadek zyskowności kopania u górników i kopalni.

 

Dzięki Segregated Witness a teraz również kompaktowym blokom, będzie można zmieścić dużo więcej transakcji przy mniejszym wykorzystaniu łącz niż obecnie. Deweloperzy Bitcoin Core opóźniają samo zwiększenie bloku co może budzić kontrowersje, jednak w zamian dają rozwiązania dzięki którym zwiększenie w przyszłości bloku do 2MB zamiast podwojenia przepustowości da dużo lepsze efekty.

 

Kompaktowe bloki już są testowane przez jedną z największych kopalni BTCC a wyniki są ponoć obiecujące. Czas pokaże, czy są one lepsze od rewolucyjnego Xthin autorstwa Bitcoin Unlimited.