Podsumowanie drugiej konferencji „Scaling Bitcoin”

W dniach 6-7 grudnia 2015 odbyła się w Hong Kongu druga konferencja “Scaling Bitcoin”. Możemy już na chłodno zebrać to, co zostało zaprezentowane i zrobić jej podsumowanie. Najbardziej interesującym jest oczywiście temat zwiększenia wielkości bloku, który jest głównym tematem niemal każdego wystąpienia.

 

 

 

 

W dniach 6-7 grudnia 2015 odbyła się w Hong Kongu druga konferencja “Scaling Bitcoin”. Możemy już na chłodno zebrać to, co zostało zaprezentowane i zrobić jej podsumowanie. Najbardziej interesującym jest oczywiście temat zwiększenia wielkości bloku, który jest głównym tematem niemal każdego wystąpienia.

 

Jako, że o sposobie wprowadzenia zmiany (lub nie wprowadzenia) decydują górnicy, wszystkie oczy skierowane są na przedstawicieli największych obecnie kopalni (F2Pool, BTCC, BW) oraz firm produkujących koparki (KnCMiner, Avalon, Bitmain, BitFury). Dzięki temu, że konferencja miała miejsce w Hong Kongu, obecni byli na niej wszyscy przedstawiciele większych kopalń.

 

Przedstawiciel firmy Bitman – Zhibiao zaznaczał, że górnicy są postawieni w roli sędziów, którzy mają rozstrzygnąć o dalszych losach i kierunku rozwoju Bitcoina. Jednakże nie mają oni obecnie wystarczających danych, aby zgodnie poprzeć konkretną propozycję.

 

Dyskusja toczyła się pomiędzy wprowadzeniem BIP100 (gdzie górnicy głosują nad kolejną zmianą max wielkości bloku) a BIP101 (który arbitralnie zakłada w jakim tempie max wielkość bloku ma rosnąć). W stronę BIP100 skłaniają się Bitmain i BTCC, jednak Zhibiao zaznacza, że to developerzy najlepiej rozumieją jak działa sieć i to oni powinni wyklarować najlepsze technicznie rozwiązanie.

 

BIP101 nie budzi entuzjazmu Chińczyków, ze względu na jakość/przepustowość połączeń internetowych Chiny-reszta świata. Powiększenie maksymalnego rozmiaru bloku do 8MB w chwili obecnej może skutkować problemami z przesyłaniem tak dużej paczki danych w wymaganym krótkim czasie, co może doprowadzać do powstawania większej niż zwykle ilości osieroconych bloków („orpahnów”) a nawet krótkich rozgałęzień w sieci („forków”) spowodowanych brakiem synchronizacji pomiędzy częściami sieci.

 

Problemy takie są oczywistą stratą dla kopalni i górników, a dla użytkowników oznacza to konieczność odczekania większej niż obecnie ilości potwierdzeń aby uznać transakcję za bezpieczną, jednak są to wartości bardzo małe zarówno jeśli chodzi o stratę jak i czas.

 

Developer Peter Todd zaznaczył, że presja środowiska na zwiększenie wielkości bloku jest być może nie potrzebna, bowiem prace nad mikropłatnościami (które są źródłem problemów z szybkością i przepustowością sieci) obsługiwanymi w łańcuchu bocznym z protokołem Lighting są na tyle zaawansowane, że problem zostanie rozwiązany zanim stanie się palący.

 

Protokół Lighting zakłada możliwość zasilania łańcucha bocznego przez BTC po stałym kursie wymiany, tak samo monety mogą wrócić z Lighting do BTC. Wszystkie operacje na monetach w Lighting są niezauważalne dla BTC i w żadnym stopniu nie obciążają sieci BTC. Jedynie operacje zasilenia/wycofania środków Lighting są widoczne w łańcuchu BTC.

 

Uniknięcie hardforka (a nawet kilku w przyszłości w przypadku niektórych propozycji) wymagającego aktualizacji oprogramowania u wszystkich użytkowników bitcoina wydaje się być jednym z bardziej popieranych kierunków rozwoju.

 

Pomimo optymistycznego głosu Todda, developer Jeff Garzik proponuje jednak wprowadzenie hardforka (BIP102), który rozwiąże (a właściwie odsunie w czasie) obecny problem i pozwoli na dopracowanie innych, ostatecznych rozwiązań. Ponadto ma to być sygnał dla przyszłych użytkowników, że Bitcoin nie jest w stagnacji tylko się rozwija i zwiększanie opłat transakcyjnych (w przypadku pozostawienia wielkości bloku) nie będzie środkiem odstraszającym potencjalnych użytkowników. Jego zdaniem, zwiększanie bloku powyżej 2MB (2x więcej niż obecnie) nie jest konieczne, a może być ryzykownym posunięciem.

 

„Segregated witness”

 

Innym sposobem na ominięcie limitu 1MB jest propozycja „Segregated witness” prezentowana przez Pietera Wuille.

 

Rozwiązanie to jest o tyle ciekawe, że nie wymaga wprowadzenia hardforka w sieci, a jedynie softforka obejmującego (co najmniej) węzły kopalni. Propozycja ta polega na wydzieleniu części transakcji zawierającej podpisy przy dodawaniu ich do bloku, przez co otrzymujemy około 75% oszczędności miejsca (obecnie przy 1MB bloku danych około 0.75 MB zajmują podpisy).

 

Tak więc „nowy” 1MB blok mieści tyle transakcji w nowym trybie, ile mieściłby 4MB blok zapisujący kompletne transakcje jak dotychczas. W chwili obecnej, każde wejście transakcji jest podpisane i podpis jest częścią wejścia, w wersji „Segregated witness” popisy nie są częścią transakcji i są składowane nie w bloku danych a w części transakcji nagrody za blok (transakcja generacji – „coinbase transaction”) – podobnie jak P2Pool dzieli nagrodę za blok.

 

Dla węzłów nie obsługujących nowego trybu wyglądałoby to jakby transakcje były niekompletne (czyli nie byłyby przekazywane ani akceptowane), ale bloki byłyby prawidłowe. Tak więc stany kont byłyby aktualizowane po każdym bloku, „stare” programy nie mogłyby monitorować przychodzących transakcji. Dodatkowo nowy protokół rozwiązuje problem „transaction malebility”, ponieważ hasz transakcji obejmuje tylko wejścia i wyjścia, bez podatnych na modyfikacje podpisów. Powstałaby więc „dodatkowa” baza danych podpisów, która nie jest wliczana w wielkość bloku danych. Tak więc danych w bloku faktycznie byłoby więcej, ale zgodnie z protokołem „zaliczane” byłoby tylko max 1MB.

 

Minusem tego rozwiązania jest konieczność znacznych modyfikacji w kopalniach, ponieważ proces tworzenia bloku ulega znaczącym zmianom. Umieszczenie danych w transakcji generacji wymaga dodatkowych operacji, ponadto utrudnia to składowanie potencjalnych bloków w pamięci kopalni, jako że transakcja generacji jest pierwszą rzeczą którą kopalnia musi zbudować aby otrzymać nagrodę za blok. Dodanie każdej nowej transakcji do bloku będzie wymagać więcej obliczeń niż dotychczas.

 

Pieter Wuille jest otwarty na dyskusje i propozycja ta ma być przedstawiona w formie kolejnego BIPa. Inny deweloper Jonathan Toomim uważa, że zmiana taka powinna zostać dopracowana i wdrożona w formie hardforka, aby uczynić ją jak najbardziej bezpieczną i wydajną.

 

Ponieważ pomysłów na zwiększanie wielkości bloków jest wiele (BIP 100, BIP101, BIP 103, BIP 105, BIP 106, BIP 248) tymczasowo wydaje się wygrywać propozycja BIP102 zwiększająca blok do 2MB i dająca nam więcej czasu na analizę i wdrożenie innego/finalnego rozwiązania. W związku z tym, nieuniknionym wydaje się być pojawienie się najbliższym czasie co najmniej jednego hardforka związanego z wielkością bloku.

 

Jako że hardfork wymaga zmiany oprogramowania u wszystkich użytkowników, w momencie jego wprowadzenia warto by wprowadzić jak najwięcej usprawnień. Odsuwając go w czasie, możemy otrzymać jedną dużą zmianę, która będzie zawierać wiele nowych funkcjonalności i znacznie poprawi działanie całej sieci. Problem wielkości bloku nie jest bowiem jedynym, z jakim boryka się Bitcoin.

 

Na dzień dzisiejszy mimo wydającej się przewagi BIP102 również „Segregated witness” zostało przyjęte z dużym entuzjazmem dlatego przejście na BIP102 nie jest takie pewne. Bitcoin XT będący gotowym rozwiązaniem które można wprowadzić w każdej chwili, wydaje się, że odszedł na boczny tor ze względu na niechęć chińskich kopalń.

 

Podsumowując konferencja nie przyniosła konsensusu ale niewątpliwie do niego nas przybliżyła. Jak widzimy też, z czasem powstają coraz to nowsze pomysły i wizje rozwoju i działania Bitcoina. Wprowadzenie BIP102 aby wydłużyć czas na ostateczne rozwiązanie problemu wielkości bloków nie jest złym pomysłem pod warunkiem, że popularyzacja Bitcoina nagle nie wzrośnie w gwałtownym tempie. Jeśli miało by to miejsce wówczas można skorzystać z gotowego i przetestowanego rozwiązania w postaci Bitcoin XT.

 

Materiały video z konferencji dostępne na kanale YouTube