Ostatni “stress test” sieci Bitcoin, który rozpoczął się 9 września 2015 roku, był już omawiany wielokrotnie na portalach związanych z kryptowalutami, bitcoinowych forach internetowych i blogach. Napisano sporo, ale tak naprawdę ciężko znaleźć analizę skutków i wpływu “testu” na działanie infrastruktury Bitcoina.
“Stress test” oraz “test” pisany jest celowo w cudzysłowie, ponieważ nie ulega wątpliwości, że wspomniana akcja była mniej testem, a bardziej atakiem na sieć Bitcoin, a jeszcze bardziej działaniem marketingowym pewnej firmy. Zresztą, tę kwestię, jak również schemat przeprowadzonego ataku opisałem we wcześniejszym poście (czyt. Filantropia jako forma ataku). O ile poprzedni, majowy eksperyment, mógł dostarczyć ciekawych informacji związanych z działaniem sieci Bitcoin pod dużym obciążeniem, o tyle wrześniowy nie miał najmniejszego sensu z technicznego punktu widzenia.
Jak już wspomniałem, w kontekście wrześniowego “testu” większość artykułów oraz wpisów na forach i blogach koncentrowała się głównie na sensie lub bezsensie całej akcji. Dla wielu był to również pretekst do podniesienia kwestii rozmiaru bloku w łańcuchu bloków, a ostra dyskusja, żeby nie powiedzieć wojna słowna, na dobre rozgorzała pomiędzy zwolennikami Bitcoin XT, a zwolennikami Bitcoin Core. Majowy test natomiast zaowocował m.in. ciekawą analizą sporządzoną przez serwis TradeBlock.
Wykresy
Na wzór analizy wykonanej przez TradeBlock, warto przyjrzeć się jak wyglądała sieć Bitcoin tuż przed “stress testem”, w jego trakcie i chwilę po zakończeniu. Poniżej zamieszczę kilka zrzutów ekranu prezentujących ciekawe informacje.
Na pierwszy ogień idą niepotwierdzone transakcje. W szybkim tempie ich liczba wzrosła do ponad 110 tysięcy skutkując zwiększeniem rozmiaru mempool do ponad gigabajta. Po około 4 dniach sytuacja wróciła do normy.
 |
| Wykres przedstawiający liczbę niepotwierdzonych transakcji podczas wrześniowego "stress testu" |
Na początku października tego roku firma, która rozpoczęła “stress test”, zebrała resztki Bitcoinów z adresów, których kluczy prywatnych nie udostępniła, co wywołało kolejne duże obciążenie sieci. Możemy o tym przeczytać m.in. w dyskusji dot. “testu” na bitcointalk.org
 |
| Wzrost liczby niepotwierdzonych transakcji podczas październikowego zbierania "pyłków" bitcoinowych |
A tutaj możemy zobaczyć jednocześnie jak wyglądał mempool we wrześniowym “stress teście” oraz podczas październikowego “zbierania” pozostałych bitcoinów.
 |
| Liczba niepotwierdzonych transakcji, odrzucone transakcje i stosunek outputów do inputów w okresie zawierającym "stress test" (początek września) i zbieranie "pyłków" (początek października). |
Warto się przyjrzeć jak zmieniał się wykres “Transaction Accepted vs Rejected”. Udostępnienie na forum bitcointalk kluczy prywatnych skutkowało tym, że wiele osób zaimportowało te same klucze i próbowało wydać te same inputy, co z kolei wygenerowało wiele transakcji, które zostały odrzucone. Inną ciekawą rzeczą jest wykres “% Transaction Inputs vs Outputs”. W okolicach 8-9 października w transakcjach przeważały inputy, co bardzo ładnie obrazuje zbieranie “pyłków” bitcoinowych i wysyłanie ich na zbiorczy output firmy odpowiedzialnej za spam test, tfu, "stress test".
Jeśli ktoś ma ochotę, to może samemu się pobawić i analizować działanie sieci np. z wykorzystaniem serwisu statoshi.info, bądź tradeblock.com. Warto mieć na uwadze również pewne różnice w wyświetlonych danych pomiędzy statoshi.info, a tradeblock.com. Tutaj przede wszystkim mam na myśli liczbę niepotwierdzonych transakcji w październiku. Na TradeBlock liczba niepotwierdzonych transakcji w październiku była prawie taka sama, jak podczas wrześniowego “stress testu”, tj. ponad 100 tysięcy. Z kolei na statoshi.info liczba niepotwierdzonych transakcji w październiku była dwukrotnie niższa, niż podczas “stress testu”. Dodatkowo po osiągnięciu swojej maksymalnej wartości nieoczekiwanie pikuje, później wraca ponownie do maksimum, utrzymuje się tak kilka kolejnych dni, znowu pikuje, jeszcze raz wraca na maksa i rozładowuje się całkowicie 26 października. Na moje skromne oko, po “stress teście” wprowadzono w statoshi.info limit liczby przechowywanych niepotwierdzonych transakcji.
Odczuwalne skutki “stress testu”
Tyle z wykresów. Jakie były odczuwalne skutki samego “stress testu”? Czy transakcje nie dochodziły do skutku, bądź były potwierdzane z duzym opóźnieniem? Otóż tak naprawdę “stress test” nie miał prawie żadnego wpływu na zwykłych użytkowników Bitcoina. Jeśli ktoś nie obniżał standardowej prowizji, a zaufał domyślnemu działaniu portfela - pieniądze dochodziły bez żadnych opóźnień. Sam z czystej ciekawości w momencie największego (jak się później okazało) rozmiaru mempoola wysłałem 5 mBTC, a transakcja została zatwierdzona w pierwszym wygenerowanym bloku. Ale napisałem “PRAWIE żadnego wpływu”, ponieważ na pewno zauważalne było zwiększenie wykorzystanie pamięci operacyjnej przez Bitcoin Core (oficjalny klient Bitcoina), będące oczywistym skutkiem gwałtownego wzrostu mempoola. Jeśli ktoś ma mało RAM-u, to coś się mogło wysypać. Oczywiście system powinien ubić proces, który zużywa za dużo pamięci, ale to nie w każdej sytuacji może być akceptowalne zachowanie. Niektórzy wymagają, aby node (np. Bitcoin Core) działał non-stop. Można się przed tym zabezpieczyć (tak zrobili to w statoshi.info), zmieniając w konfiguracji opcje minrelaytxfee lub limitfreerelay (czyt. dokumentacja) albo jeśli ktoś korzysta z alternatywnego klienta Bitcoin XT, ustawić opcję maxmempooltx.
Wniosek wysuwa się taki, że Bitcoin, dzięki swoim mechanizmom samoregulacji, jest naprawdę odporny na wszelkiego rodzaju ataki. Oczywiście społeczność Bitcoina musi zmierzyć się z kilkoma problemami, jak np. co dalej zrobić z ograniczeniem rozmiaru bloku do 1MB, gdy pomału sieć zaczyna osiągać ten limit. Ale na ten temat, mam nadzieję, będziemy wiedzieć więcej już po konferencji Scaling Bitcoin w Hong Kongu.
0 komentarze: