Sytuacja po konsensusie w sprawie wielkości bloków – rośnie popularność Bitcoin Classic

Mimo ostatniego konsensusu, który miał zakończyć wielomiesięczny spór o maksymalny rozmiar bloku w sieci Bitcoin, społeczność oraz przedstawiciele firm bitcoinowych nie dają za wygraną.

 

 

Mimo ostatniego konsensusu, który miał zakończyć wielomiesięczny spór o maksymalny rozmiar bloku w sieci Bitcoin, społeczność oraz przedstawiciele firm bitcoinowych nie dają za wygraną.           

 

Według informacji z serwisu NodeCounter Bitcoin Core po raz pierwszy w historii ma mniej niż 75% pracujących węzłów w sieci Bitcoin. Jednocześnie Bitcoin Classic ociera się o kolejny próg: ma już niemal 20% węzłów. Pokazuje to, że społeczność użytkowników Bitcoin jest wyjątkowo niezadowolona z kierunku jaki obrali deweloperzy Core i szukają alternatywnego rozwiązania.

 

Oczywiście, żeby zmiany zaproponowane w Classic mogły wejść w życie, operatorzy kopalni muszą zmienić swoje oprogramowanie i wyrazić gotowość do wprowadzenia zmian. Na chwilę obecną widać rosnącą popularność Classic również w wykopanych blokach, wciąż jest to jednak mniej niż 5% wszystkich bloków. Aby zmiany doszły do skutku, Classic wymaga przekroczenia 75% bloków oznaczonych jako zgodnych z Classic.

 

Tu warto zaznaczyć, że poparcie dla Classic ogłosiła też jedna z największych kopalń F2Pool (25% mocy), za co stała się celem ataku DDOS ze strony wielbicieli Bitcoin Core. Tu warto zaznaczyć też, że atak DDOS również skierowany jest przeciwko nodom Bitcoin Classic.

 

Ostatni konsensus oraz problem wielkości bloku jest, tematem trwającego od 26 lutego posiedzenia „Okrągłego Stołu Satoshiego” skupiającego społeczność oraz przedstawicieli firm bitcoinowych.

           

Autor BIP102 (którego nieco zmodyfikowaną wersję jako BIP109 implementuje Clasic), Jeff Garzik, wyraził swoje zadowolenie z wyników w/w posiedzenia, które pokrywają się z jego wcześniejszymi propozycjami i założeniami.

 

Jednocześnie deweloperzy Classic opublikowali swój plan rozwoju Bitcoina czyli RoadMap na 2016. W planach również znajdziemy SegWit z Core, wcześniej jednak wprowadzając zmianę wielkości bloku.

 

Harmonogram wprowadzenia zmian na 2016 rok wg Classic:

 

Faza 1: pierwsze półrocze – wprowadzenie BIP109 zwiększającego blok do 2MB z 75% poparciem kopalni, kod oparty na Core 0.11.2 i 0.12.0

Faza 2: drugi i trzeci kwartał: wprowadzenie zmian pomagających w propagacji nowych bloków i zmniejszających ruch generowany przez sieć:

 

• równoległa weryfikacja bloków,
•  kopanie po otrzymaniu nagłówka bloku,
•  „cienkie” bloki (brak konieczności przesyłania kompletnego nowego bloku po jego wykopaniu)
•  „słabe” bloki (możliwość rozgłaszania przez kopalnie bloków nad którym pracują)
•  jednokrotna weryfikacja (otrzymana transakcja nie będzie weryfikowana więcej niż raz, tylko po otrzymaniu – obecnie jest również weryfikowana przy dołączaniu do bloku)

 

Faza 3: drugie półrocze:

 

•  wprowadzanie mechanizmu automatycznej regulacji maksymalnej wielkości bloku (wersja zaproponowana przez BitPay). Jest to chyba najważniejsza zmiana, która definitywnie zakończyłaby całe zamieszanie wokół wielkości bloku, który regulowany byłby automatycznie tak jak trudność.
•  wprowadzenie SegWit z Core

 

Aktualne stanowisko deweloperów Core budzi coraz więcej sprzeciwów w społeczności Bitcoin, ponieważ forsują oni rozwiązania, które nie rozwiązują skutecznie problemu kurczącego się dostępnego miejsca w blokach (nie powiększają limitu) a wprowadzają rozwiązania, które mają użytkownikom pomóc „przepchnąć” transakcje (RBF i zwiększanie opłaty). Z oczywistych powodów jest to przez użytkowników źle odbierane, gdyż przelewy Bitcoin stają się coraz droższe a czas oczekiwania na potwierdzenie transakcji stale rośnie.

 

Dla deweloperów Core lekarstwem na wszystko wydaje się być zwiększanie opłat, bez wprowadzania zmian w protokole. Dla właścicieli kopalni takie stanowisko może być kuszące (bo nagroda za blok rośnie) ale powoduje też wstrzymanie rozwoju sieci, ze względu na utratę dwóch podstawowych argumentów które przyciągają do Bitcoin: szybkość transakcji i ich relatywnie niska cena. W ten sposób deweloperzy Core i kopalnie przysłowiowo “strzelają sobie w stopę”, gdyż przez krótkotrwały wzrost dochodów powodują zatrzymanie rozwoju całego projektu.

 

Kolejnym powodem niechęci społeczności w stosunku do deweloperów Bitcoin Core jest fakt, że część z nich pracuje dla Blockstream, czyli dla projektu łańcuchów bocznych. Z punktu widzenia Blockstream, “upośledzenie” Bitcoina w postaci jego zapchania i wysokich prowizji jest korzystne dla ich interesu. Blockstream będzie promowany jako szybka alternatywa dla samych transakcji Bitcoinowych, więc jak najgorsze i jak najwolniejsze działanie samego Bitcoina ma pomóc im w popularyzacji swojego projektu. Ostatnie doniesienia sugerują też, że Blockstream jest kontrolowany przez AXA Strategic Ventures, uczestnika niedawnej rundy finansowania Blockstream kwotą 55mln$. Blockstream stał się więc narzędziem korporacji a jego pracownicy stanowią główną siłę deweloperów samego Bitcoina, co jest niewątpliwym konfliktem interesów, szczególnie dla bitcoinowej społeczności.

 

Coraz większa część środowiska dostrzega, też zalety szybkiego wprowadzenia zmiany wielkości bloku, co owocuje rosnącą ilością węzłów kompatybilnych z nadchodzącymi zmianami. W swoim poście Jeff Garzik wskazuje podstawowe problemy jakie widzi w działaniu deweloperów Core:

 

1. Kompleksowość zmian wprowadzanych przez SegWit: aktualizacja oprogramowania zgodnego z SegWit musi odbyć się na wielu poziomach i są to znaczące zmiany w kodzie kopalni, procesorów płatności, giełd i samych użytkowników. Aby SegWit dało zauważalne korzyści musi go używać znacząca większość użytkowników.

 

2. Brak określonych terminów: deweloperzy Core nie określili precyzyjnie w jakim czasie SegWit ma być wdrożone i uruchomione. Nie można więc określić kiedy faktycznie zacznie mieć wpływ na transakcje i sytuację panującą w sieci.

 

3. SegWit nie rozwiązuje problemu: pomimo dużego stopnia komplikacji SegWit nie rozwiązuje problemu wielkości bloku, przy opanowaniu większości transakcji w sieci będzie jedynie mechanizmem dającym nieco więcej czasu.

 

4. Wprowadzenie SegWit jako softfork: z ekonomicznego punktu widzenia może być błędem, ponieważ nie zmusza do aktualizacji oprogramowania. Użytkownicy są z zasady nieufni i leniwi. Jeżeli stara wersja Core będzie nadal działać prawidłowo (a będzie) spora cześć użytkowników nie wykona aktualizacji przez co może być narażona na oszustwa, które umożliwi RBF. W skrócie użytkownicy, starych wersji oprogramowania nie będą widzieć oznaczenia transakcji jako RBF, które można cofnąć jeśli nie zostały jeszcze potwierdzone przez sieć.

 

5. Zbyt wysoki próg Hard Forka: z punktu widzenia teorii gier już 90% mocy sieci jest bardzo wysokim i wystarczającym progiem. 95% oznacza, że wystarczy mieć dostęp do 5% mocy sieci aby zablokować wprowadzenia Hard Forka.

 

6. Dobór parametrów czasowych Hard Forka: należy konkretnie określić czas w jakim Hard Fork ma wejść w życie po przekroczeniu % progu. Zbyt krótki czas (np., mnij niż miesiąc) może spowodować, że nowe bloki będą odrzucane przez sporą część wciąż „użytecznych” węzłów, wydłużenie czasu do roku, lub wręcz nie zwiększanie bloku przez Hard Fork spowoduje zastój w rozwoju projektu i odejście użytkowników nie widzących szans na dalszy rozwój. Czas ten musi być jawnie przedstawiony i wdrożony po zaaprobowaniu przez społeczność.

 

7. Ewentualny rollback: użytkownicy muszą wiedzieć jak transakcje będą rozchodzić się po sieci w momencie Hard Forka i czym grozi ewentualne „cofnięcie” bloków jeżeli coś pójdzie nie tak.

 

8. Zarządzanie projektem: praktycznie cały rok 2015 wszyscy dopytywali się „jak, kiedy i o ile zwiększamy blok”. Deweloperzy Core nie dali jasnej odpowiedzi na to pytanie, Classic natomiast od razu jasno określił te kroki. Dobrze, że jest zgoda w obu forkach co do konieczności zmiany, jednak opóźnianie działania przez Core i wprowadzanie „działań zastępczych” nie pokazuje użytkownikom jasnego stanowiska.

 

 

Kroki do podjęcia (zdaniem Jeffa Garzika):

 

• ustalenie daty wprowadzenia Hard Forka do 2MB, ogłosić tą datę we wszelkich mediach dając czas użytkownikom sieci na przygotowanie. Czas 28 dni jest zbyt krótki na wprowadzenie „produkcyjne”, może być jednak dobrym „awaryjnym” czasem jeżeli Hard Fork będzie musiał być wprowadzony w trybie nagłym. Czas wprowadzenia produkcyjnego powinien się zamknąć w 3-6 miesiącach od ogłoszenia.
• wprowadzenie SegWit nie może blokować wprowadzenia innych zmian – kolejnie zmiany nie mogą wymagać wcześniejszego wdrożenia SegWit
• zorganizowanie prac na wzór działania IETF – aby wszystko było jawne a informacje powszechnie i szybko dostępne

 

 

Czy obecna sytuacja jest szkodliwa dla projektu?

 

Obecnej sytuacji z nie można nazwać kontrowersyjnej czy też szkodliwej dla projektu, gdyż jest to naturalny proces przy niemal każdym projekcie Open Source. Otwarte oprogramowanie przyciąga wielu programistów, którzy stają się oficjalnymi deweloperami projektu. Ci zaś łączą się w grupy, jest to proces całkowicie naturalny. Wiodąca grupa, może nie dopuszczać rozwiązań innych programistów, tworząc monopol na swoją wizję rozwoju projektu. Wizja ta często jest różna od wizji społeczności, która korzysta z samego projektu. Bitcoin jednak jest szczególnym rodzajem projektu otwarto źródłowego, który umożliwia radzenie sobie z w/w problemami. Struktura Bitcoina jest trzy częściowa:

 

1. Społeczność – czyli wszyscy użytkownicy korzystający z projektu, mający wpływ na kurs BTC, który to zależy od użyteczności samego projektu oraz możliwości jego rozwoju

2. Kopalnie – zatwierdzają wszelkie zmiany w projekcie. Ich dochód zależny jest, od kursu BTC, a więc od samej społeczności

3. Deweloperzy – proponują zmiany w projekcie jednak, aby zostały wprowadzone, musi być zgoda kopalń. Same zaś kopalnie muszą działać zgodnie z interesem społeczności, inaczej skazane są na bankructwo.

 

W takiej strukturze, główna władza należy, więc do samej społeczności. Wiodąca grupa deweloperów ma jedynie władzę nad proponowanymi zmianami, lecz można ją wymienić na inną.

 

W tym przypadku chodzi o wymianę deweloperów Bitcoin Core na deweloperów Bitcoin Classic. Samych grup deweloperów jest więcej, jak np. Bitcoin Unlimited czy Bitcoin NG. Właściwie, im więcej grup rywalizujących ze sobą, tym lepiej. Społeczność może wybrać tych, którzy ich zdaniem zapewniają najlepsze rozwiązania i możliwość rozwoju.

 

Obecnie mamy powszechną zgoda na uruchomianie Hard Forka do 2MB,   kolejne tygodnie pokażą czy użytkownicy i kopalnie będą cierpliwie czekać na zmiany w Core, czy też Core przez zbyt konserwatywne podejście odejdzie do lamusa i nowym „oficjalnym” klientem Bitcoin zostanie Classic.

 

Zdjęcie:twitter.com/SatoshiRoundtbl