BIP0102 – konsensus z powodu braku konsensu

Na repozytorium GIT Bitcoin Core, Jeff Garzik podał nową propozycję zmiany w kodzie oznaczoną jako BIP0102, dotyczącą wprowadzenia maksymalnej wielkości bloku.

 

 

Na repozytorium GIT Bitcoin Core, Jeff Garzik podał nową propozycję zmiany w kodzie oznaczoną jako BIP0102, dotyczącą wprowadzenia maksymalnej wielkości bloku.

 

Jak wcześniej pisaliśmy, powstały już dwie wersje propozycji zmian maksymalnej wielkości bloku – BIP100 i BIP101. To, że zmiana jest konieczna jest już oczywiste i nikt tego nie neguje. Większy rozmiar bloku ma zapobiegać między innymi sytuacjom takim jak ta która ma miejsce od pewnego czasu, czyli trwających od kilku dni problemów sieci Bitcoin, która jest zarzucona dużą ilością oczekujących na włączenie do bloków transakcji.

 

Zbyt duża jak na obecny rozmiar bloku ilość transakcji powoduje częste opóźnienia w wysyłanych transakcjach – czas, który uznawaliśmy za „pewny” wydłużył się nawet kilkukrotnie w przypadku transakcji bezprowizyjnych. Zmiana wielkości bloków zwiększy przepustowość całej sieci pozwalając na realizację większej ilości transakcji na sekundę oraz spowoduje, że Spam Atak jaki mieliśmy ostatnio stanie się jeszcze bardziej kosztowny. Jest to zatem, kluczowa zmiana dla dalszego rozwoju sieci Bitcoin jako formy płatności.

 

Czym różni się propozycja BIP0102 od wcześniejszych?

 

Zmiana ta wprowadza hardfork (zmiana wymagająca od wszystkich aktualizacji programu klienta) na dzień 11. listopada 2015 roku (timestamp 1447200000; 11 Nov 2015 00:00:00 UTC) i zwiększa maksymalną wielkość bloku do 2MB. Nie zawiera żadnych późniejszych zmian.

Zmiana ta nie jest w żaden sposób głosowana ani przeliczana (jak robi to BIP100), po prostu każdy blok ze znacznikiem czasu wyższym niż podany może mieć już maksymalnie 2MB zamiast 1MB.

 

Co to oznacza?

 

Jeżeli zmiana ta zostanie włączona do kodu i wypuszczona zostanie kolejna wersja Core, mamy czas do listopada aby zaktualizować nasze portfele. Co prawda „lekkie” portfele nie trzymające całych bloków nie odczują tego w żaden sposób, o tyle wszyscy użytkownicy Core i innych programów weryfikujących/analizujących strukturę bloków będą musiały być zaktualizowane.

 

Istnieje oczywiście możliwość, że kopalnie nie przyjmą tej zmiany. Jeżeli ponad 50% mocy sieci będzie w rękach kopalń nie obsługujących BIP0102 to ich łańcuch będzie dłuższy i kopalnie które mogłyby budować większe bloki i tak uznają mniejsze za prawidłowe. Jednocześnie większe bloki będą „osierocane” i kopalnie które je będą budować nie będą zarabiać.

 

Nawet po ewentualnym wprowadzeniu tej zmiany w kodzie i uzyskaniu ponad 50% mocy przez kopalnie obsługujące BIP102, to czy przepustowość zwiększy się dwu krotnie i tak zależeć będzie od tych kopalń które nie zgodziły się na zmiany, ponieważ nawet nie przyjęcie przez nie zmian spowoduje, że budowane przez nie bloki będą prawidłowe mimo, że są mniejsze. Stanie się tak, ponieważ nie można ograniczyć wielkości bloku „od dołu” (może się przecież zdarzyć, że nikt w danym momencie nie będzie wysyłał transakcji) bloki o wielkości mniejszej niż maksymalna (zawierające nawet 1 transakcję).

 

Mamy już trzy wersje proponowanych zmian:

• BIP100 (jgarzik)– włączenie (w listopadzie 2015) możliwości zmiany wielkości bloku co 3 miesiące przez głosowanie kopalni (max x2 lub /2 w zależności od wyniku głosowania), górny limit 32MB zostaje
• BIP101 (gavinandresen)– zwiększenie max wielkości bloku na 8MB (w styczniu 2016) i automatyczne podwajanie wielkości co 2 lata, aż do 8GB za 20 lat
• BIP102 (jgarzik) – zwiększenie (w listopadzie) max wielkości bloku do 2MB

 

Nowa propozycja wydaje się więc być rozwiązaniem zastępczym, graniem na czasie i odłożeniem problemu na później. Blok wielkości 2MB powinien wystarczyć na najbliższe kilka-kilkanaście miesięcy i skutecznie odstraszyć potencjalnych atakujących (spam atakiem), ale nie rozwiązuje problemu długotrwale. Problem, wielkości bloków zostanie otwarty.

 

Fotografia na licencji Creative Commons: Flickr.com