Manifest developerów Bitcoin Core – echa konferencji „Scaling Bitcoin”

Na konferencji w Hong Kongu pojawiło się kilka nowych pomysłów w temacie zwiększenia przepustowości sieci Bitcoin. Po konferencji deweloper Gregory Maxwell sformułował założenia, jakie zmiany chciałby wdrożyć w najbliższym czasie w protokół Bitcoina. Postaramy się streścić jego manifest.

 

 

Na konferencji w Hong Kongu pojawiło się kilka nowych pomysłów w temacie zwiększenia przepustowości sieci Bitcoin. Po konferencji deweloper Gregory Maxwell sformułował założenia, jakie zmiany chciałby wdrożyć w najbliższym czasie w protokół Bitcoina. Postaramy się streścić jego manifest.

 

Pod manifestem podpisało się 32 developerów Bitcoin Core, wyznacza on tym samym dalszy kierunek rozwoju Bitcoina.

 

Gregory zakłada, że wprowadzanie zmian jest konieczne dla dalszego rozwoju Bitcoin, lecz zmiany te muszą być wprowadzane w sposób maksymalnie przeźroczysty dla „zwykłego” użytkownika.

 

Podstawowym założeniem jest więc używanie „soft-forków” (miękkich rozgałęzień) w sieci, aby nie wymuszać za każdym razem do aktualizacji oprogramowania przez wszystkich użytkowników. Ponadto, cały obecnie używany kod powinien być dalej optymalizowany, aby w przyszłości, przy większej ilości transakcji, nie było problemów z mocą obliczeniową konieczną do uruchomienia węzła sieci.

 

Jedną z takich optymalizacji jest np. użycie biblioteki libsecp256k1, dzięki której weryfikacja podpisów odbywa się znacznie szybciej. Porównując wersję Core 0.12 do wcześniejszych, uzyskano np. ponad 7x przyspieszenie łączenia bloków w łańcuch („ConnectTip performance”) podczas synchronizacji i pobierania kolejnych, nowych bloków. Kolejne optymalizacje powinny zmniejszyć zapotrzebowanie Core na moc obliczeniową pomimo zwiększającej się ilości transakcji.

 

Wprowadzanie kolejnych zmian ma odbywać się z użyciem dopracowywanego BIP-9. BIP ten ma zastąpić obecnie używany do głosowania BIP34/66. BIP9 daje dużo więcej możliwości niż 34, między innymi umożliwia głosowanie za wprowadzaniem wielu zmian w tym samym czasie, głosowanie byłoby również ograniczone czasowo (jeżeli kopalnie przez określony czas nie zgadzały się na konkretną modyfikację głosowanie wygasałoby).

 

Można będzie również głosować kilka wersji jednej poprawki, a protokół nie pozwoli na wejście w życie wykluczających się zmian (nie będą mogły być uruchomione zmiany wzajemnie wykluczające się).

 

Jedną z pierwszych zmian jakie Gregory widzi do wprowadzenia, jest zwiększenie pojemności łańcucha przez przyjęcie protokołu „Segregated Witness” Pieter Wuille. Zmiana ta pozwala na ok 4x zwiększenie przepustowości sieci i może być wprowadzona jako soft-fork. Dodatkowo zmiana ta może umożliwić szybszą synchronizację nowego węzła, ponieważ znaczna część danych mogłaby być nie pobierana przez nowy węzeł. Podobne rozwiązanie zostało już wdrożone w łańcuchu bocznym Elements Alpha.

 

Poprawka wprowadzana do Bitcoin ma być ulepszona, między innymi o mechanizmy ułatwiające wykrycie możliwości podwójnego wydania (ataku „double spend”). Kod obecnie dostępny na GIT-cie jeszcze tego nie uwzględnia.

 

Kolejne zmiany jakie powinny być wdrożone do Bitcoin to zmiana sposobu przesyłania bloków. Obecnie jest kilka propozycji nazywanych “weak blocks”, “thin blocks” czy “soft blocks”. Wszystkie one opierają się na założeniu, że węzeł w sieci ma większość transakcji które są zawierane do nowego bloku, i przesyłanie całej informacji (jak jest to robione obecnie) nie jest wcale konieczne.

 

Zmiany które już są wprowadzane również maj pomóc w zwiększeniu przepustowości sieci, jest to na przykład BIP065 który zmienia sposób blokowania transakcji w czasie (obecnie transakcje musi „wisieć” w sieci i nie może być zatwierdzona, po aktywacji BIPa transakcja będzie dołączana do bloku ale nie będzie jej można wydać wcześniej niż określony czas). Zmiany takie pozwalają na zmniejszenie zapotrzebowania węzła Core na przepustowość łącza.

 

Kolejnymi zmianami na które będzie można głosować to już konkretne zmiany wielkości bloku które wymagają hard-forka. W pewnym momencie bufor miejsca jaki dało nam wprowadzenie oddzielenia podpisów zostanie wyczerpany, i wprowadzenie hardforka zwiększającego maksymalną wielkość bloku będzie niezbędne. Dzięki BIP9 będzie można nie tylko jednocześnie głosować nad wprowadzeniem (jednej lub kilku) z wielu zmian, ale będzie też można głosować nad kilkoma wariantami jednej zmiany (np. zwiększamy blok do 2,4 lub 8MB, lub zostawiamy 1MB ale dodajemy autoregulację, itp). System głosowania BIP9 nie pozwoli na wejście w życie wykluczających się zmian, a “uruchomienie” wdrożonej zmiany wymaga 95% głosów.

 

Podsumowując, Gregory uważa, że dalszy rozrój Bitcoin wymaga zmian, a ich wprowadzanie można przyspieszyć i ulepszyć przez użycie nowego systemu głosowania.

Pod jego manifestem podpisują się kolejni deweloperzy, którym jak widać również zależy na dalszym rozwoju Bitcoina.

 

Fotografia na licencji Creative Commons: Flickr.com