Problem maksymalnej wielkości bloku – aktualna sytuacja

Problem wielkości bloków nadal jest tematem numer jeden wśród bitcoinowej społeczności. Od kilku miesięcy niewiele zmieniło się w tym temacie, jednak wszyscy są zgodni co do tego, że problem należy rozwiązać jak najszybciej. Jak można się domyślić, różne są wizje ewentualnych zmian.

 

 

Problem wielkości bloków nadal jest tematem numer jeden wśród bitcoinowej społeczności. Od kilku miesięcy niewiele zmieniło się w tym temacie, jednak wszyscy są zgodn co do tego, że problem należy rozwiązać jak najszybciej. Jak można się domyślić, różne są wizje ewentualnych zmian.

 

Bitcoin XT odchodzi do lamusa

 

Pierwszym rozwiązaniem problemu wielkości bloków zdobywającym dość dużą popularność wśród społeczności był Bitcoin XT czyli BIP101. Jego autor, Gavin Adrersen, niedawno oświadczył, że wycofuje się, ze swojego pomysłu . Mimo, iż BIP101 początkowo miał spore poparcie wśród społeczności, to przez ostatnie kilka miesięcy zainteresowanie projektem było małe.

 

BIP101 był też mocno krytykowany przez chińską społeczność skupiającą kopalnie ze względu na możliwe komplikacje po jego wprowadzeniu. Chiny nadal mają problemy z połączeniem Internetu do reszty świata (tzw „great firewall of china”), który skutecznie blokuje duże jednorazowe transfery. Zwiększenie bloku do 8MB dla chińczyków teoretycznie oznaczałoby duże starty spowodowane wolną propagacją nowych bloków i powstawaniem dużej ilości bloków osieroconych (tzw „orphan block”).

 

Bitcoin Classic wysuwa się na prowadzenie

 

Największym obecnie wygranym zdaje się być propozycja Bitcoin Classic, która w krótkim czasie przeskoczyła popularnością BitcoinXT (implementujące BIP101). Liczba nodów Bitcoin Classic przekroczyła już 20% wszystkich nodów w sieci podczas gdy nody Bitcoin XT stanowią mniej niż 5%. Oczywiście to nie ilość nodów decyduje o wprowadzonej zmianie lecz kopalnie, jednak jest dość dobrym miernikiem określenia popularności danego rozwiązania.

 

Classic zakłada „proste” zwiększenie bloku do 2MB. Niestety, wszystko wskazuje na to, że jest to rozwiązanie bardzo krótkotrwałe i jego wprowadzenie nie gwarantuje długoterminowego rozwiązania problemu wielkości bloku. Jako, że popularność tego rozwiązania stale rośnie i mamy już pierwsze bloki wykopane z jego udziałem (można je rozpoznać po numerze wersji: 0x30000000 szesnastkowo lub 805306368 dziesiętne, zgodnie z „version bits”) możemy się spodziewać dalszego rozwoju projektu. Jedynym, czego w nim brakuje jest zakodowanie automatycznej regulacji wielkości bloku w przyszłości. Bitcoin Classic w obecnej formie daje nam więc czas na wprowadzenie mechanizmu autoregulacji wielkości bloków która działałaby na podobnej zasadzie co np. regulacja trudności sieci i dostosowywała wielkość bloku do potrzeb w danej chwili.

 

Jednym z prostych algorytmów, jakie możnaby zaimplementować, przedstawił już jakiś czas temu serwis BitPay – prosta mediana z wielkości ostatnich bloków. Jako, że nie sposób określić tempa rozwoju sieci i kolejnych konicznych zmian w wielkości/pojemności bloku mechanizm samoregulacji jest konieczny. Wszystkie mechanizmy zwiększające tą wartość w sposób arbitralny, mogą się całkowicie nie sprawdzić: albo powodując zatrzymanie rozwoju sieci z powodu zbyt niskiego limitu (co obserwujemy obecnie) albo pozostawiając zbyt dużo miejsca na ewentualne ataki (co mógł zafundować nam BIP101).

 

Brak wprowadzeniu takiego mechanizmu oznacza kolejność kolejnego hardforka, czyli kolejnej wymuszonej aktualizacji. Jako, że rozwiązania takiego wolimy wszyscy uniknąć, idealnym rozwiązaniem byłoby wprowadzenie takiego rozwiązania, które ostatecznie załatwiaproblem jedną zmianą. Należy również przypomnieć, że obowiązujący limit 1MB, został wprowadzony przez Satoshiego jako zabezpieczenie przed spamowaniem sieci „złymi” transakcjami. W momencie wprowadzania limitu ilość „dobrych” transakcji była nawet kilkaset razy mniejsza niż jest obecnie.

 

Bitcoin Core uparcie przy 1MB

 

Przeciwko wprowadzeniu hardforka (zmiana wymuszająca aktualizację u wszystkich użytkowników) zwiększającego maksymalną wielkość bloku są w dalszym ciągu deweloperzy Core, forsujący wprowadzenie oddzielonych podpisów („segregated witness” – „segwit”). Jako że SegWit może być wprowadzony przez softfork (nie wymaga aktualizacji u wszystkich użytkowników) jego wprowadzenie uważa się za bezpieczniejsze i prostsze niż hardfork. Podnosi się jednak co raz więcej głosów, że zmiany wymagane przez wprowadzenie SegWit w kopalniach i u wszystkich, którzy chcieliby z dobrodziejstw SegWit korzystać są na dyle duże, że porównywalne ze zmianami potrzebnymi przy hardforku. Dodatkowo, aby SegWit faktycznie wpłynął na zwiększenie przepustowości sieci konieczne jest, aby transakcje były generowane przez zgodne z SegWit oprogramowanie.

 

Dlaczego deweloperzy Bitcoin Core nie chcą zwiększenia rozmiaru bloku?

 

• Pierwszym powodem jest ryzyko związane z hard forkiem. Jednak jest to słabe wytłumaczenie gdyż, hard fork prędzej czy później będzie musiał zostać wprowadzony, rozwiązanie SegWit bez podniesienia wielkości bloku jest rozwiązaniem krótkoterminowym. Sensownym wytłumaczeniem byłby hardfork, który raz na zawsze załatwi problem rozmiaru bloku, jednak mimo istniejących propozycji, developerzy Bitcoin Core nie biorą żadnej pod uwagę, ani nie przedstawiają własnych propozycji.
• Nadmierna centralizacja. Większy rozmiar bloku, przyczyni się do zmniejszenia prowizji a co za tym idzie spamowania sieci dużą ilością transakcji. Szybszy i duży przyrost łańcucha bloków może przyczynić się do centralizacji nodów, gdyż koszt utrzymania pojedynczego noda wzrośnie. Więcej na ten temat w poprzednim artykule. Jednak problem spamowania również można rozwiązać poprzez zmianę prowizji, która właściwie ustalana jest przez kopalnie.
• Trzecim możliwym powodem, jest potencjalny plan przeniesienia mikro-transakcji do łańcuchów bocznych.
• Czwartym powodem pozostają różnego rodzaju teorie spiskowe, które głoszą, że deweloperzy z różnego powodu działają na szkodę projektu.

 

Społeczność bitcoinowa opowiada się za 2MB blokiem + Segregated Witness

 

Segregated Witness, wprowadza do sieci Bitcoina wiele cennych dodatkowych funkcjonalności i usprawnień, jednak tylko częściowo i mało wydajnie rozwiązuje problem maksymalnej wielkości bloku. Segregated Witness ma również poparcie u dwóch najbardziej liczących się deweloperów Bitcoina czyli Jeff Garzika i Gavina Andresena jednak z zastrzeżeniem, że będzie on wprowadzony wraz, ze zwiększeniem rozmiaru bloku, a nie zamiast.

 

Podobne opinie można zauważyć wśród samej społeczności. Nawet Chińska społeczność, która “straszyła” wymuszonym przez nich forkiem, coraz bardziej przychylnie opowiada się za tym rozwiązaniem (2MB + SegWit).

 

Niedawno opublikowane oświadczenie zatytułowane “zaproszenie do konsensusu” pod którym podpisali się przedstawiciele największych kopalń, farm, producentów sprzętu górniczego oraz przedstawiciele firm bitcoinowych, również nie wyklucza rozwiązania SegWit. W oświadczeniu znajdziemy dodatkowo zapewnienie, że wyżej wymienieni przedstawiciele będą dążyć do konsensusu z deweloperami Bitcoin Core, próbując ograniczyć ryzyko związane z wprowadzeniem ewentualnego hard forka.

 

Podsumowanie

 

Sytuacja w obecnej chwili wygląda więc następująco: Po jednej stronie mamy deweloperów Bitcoin Core, którzy problem wielkości bloków chcą załatwić wyłącznie (przynajmniej w ym momencie) poprzez SegWit, z drugiej społeczność wraz z największymi kopalniami, która opowiada się za bardziej skutecznym i wydajnym rozwiązaniem wielkości bloku. Blok o wielkości 2MB + SegWit byłby rozwiązaniem, zadawalającym społeczność, jednak nie jest to rozwiązanie idealne, gdyż rozwiązuje problem tylko chwilowo (jednak daje czas na poszukiwanie rozwiązanie idealnego). Chińska część społeczności chwilowo zawiesiła też plan samowolnego hardforka zobowiązując się do porozumienia (a przynajmniej próby) z deweloperami. Najbliższy miesiąc będzie więc próbą znalezienia konsensusu między społecznością, kopalniami a deweloperami Bitcoin Core. W grę wchodzi więc kilka scenariuszy:

 

1. Społeczność i deweloperzy dochodzą do porozumienia. Wprowadzony zostanie blok o wielkości 2MB + SegWit
2. Nie dojdzie do konsensusu. Chińskie kopalnie wprowadzają hard fork zwiększający wielkość bloku do 2MB. Niewykluczony SegWit.
3. Nie dojdzie do porozumienia. Chińskie kopalnie nie wykonają żadnego ruchu. Wprowadzony zostanie SegWit. Rozwiązanie problemu zwiększenia bloku zostanie przesunięte w czasie.
4. Pojawią się nowe rozwiązania.

 

Najbardziej korzystny byłby scenariusz pierwszy, jednak jeszcze lepsze byłoby opracowanie algorytmu samoregulującego. Zapewni czas na ostateczne rozwiązanie problemu wielkości bloku. Biorąc pod uwagę konsolidację kursu, spowodowaną prawdopodobnie problemem wielkości bloku, niewykluczony jest jego wzrost.

 

Drugi scenariusz, mimo iż mniej korzystny nie będzie zagrożeniem dla projektu. Doprowadzi prawdopodobnie do zmian w ekipie deweloperów bitcoina, co może odbić się korzystnie dla projektu.

 

Trzeci scenariusz, w teorii da trochę więcej czasu na dopracowanie innych rozwiązań problemu wielkości bloku, jednak może wywołać niezadowolenie wśród społeczności, co niewykluczone że, poskutkuje chwilowym spadkiem kursu. Gdyby tak się stało, chińskie kopalnie ze względu na realne ryzyko utraty zysków i wizję bankructwa najprawdopodobniej zdecydują się na hard fork zwiększający limit bloku do 2MB (ostatnia deska ratunku) co będzie równoznaczne ze scenariuszem drugim.

 

Czwarty scenariusz, może okazać się najlepszym w przypadku ostatecznego rozwiązania problemu wielkości bloku, jak i również rodzić nowe problemy i wydłużyć czas konkretnych działań, co może skończyć się podobnie jak scenariusz trzeci.

 

Fotografia na licencji Creative Commons:Flickr.com