FAQ deweloperów Bitcoin Core – plany i kierunek rozwoju Bitcoina na 2016 rok

Jako ciąg dalszy manifestu Gregorego Maxwela dotyczącego zwiększenia przepustowości sieci Bitcoin, opublikowane zostało dokładne FAQ opisujące założenia i kolejność planowanych działań w tym zakresie. Rozwiewane jest też kilka nieścisłości które pojawiają się z różnych źródeł w tym temacie.

>

Jako ciąg dalszy manifestu Gregorego Maxwela dotyczącego zwiększenia przepustowości sieci Bitcoin, opublikowane zostało dokładne FAQ opisujące założenia i kolejność planowanych działań w tym zakresie. Rozwiewane jest też kilka nieścisłości które pojawiają się z różnych źródeł w tym temacie.

Poniżej przedstawiamy tłumaczenie:

1. Jakie konkretnie technologie są zaplanowane i kiedy możemy się ich spodziewać?

Nowe technologie zostaną wdrożone gdy będą gotowe i przetestowane. Zakładamy następującą kolejność i w miarę racjonalne terminy wdrożenia zmian:

•  grudzień 2015 – włączenie „segregated witness” (SW) w testnecie
•  luty 2016 – Core v0.12.0 z weryfikacją libsecp256k1
•  luty 2016 – SW gotowe do implementacji w głównej sieci
•  marzec 2016* – Core v0.12.x – wdrożenie pierwszego softforka BIP9 – BIPy 68+112+113
•  kwiecień 2016* – Core v0.12.x -uruchomienie SW w głównej sieci
•  2016 – „cieńkie” bloki, IBLT (Invertible Bloom Lookup Table)

Daty z gwiazdkami oznaczają przewidywany czas w jakim będzie można aktywować kolejne softforki (po uprzednim przetestowaniu, weryfikacji kodu i wdrożeniu do sieci). Ze względu na sposób głosowania nie można określić dokładnej daty aktywacji wdrożonej zmiany (np. BIP066 aktywował się w lipcu 2015 po kilku miesiącach od wdrożenia a BIP65 został aktywowany w grudniu 2015 zaledwie po 5 tygodniach od wdrożenia).

– testnet SW – osobna sieć testowa (nie jako część działającego testentu) która pozwoli każdemu testować działanie rozwiązania oraz pracować nad działaniem portfeli

– weryfikacja libsecp256k1 – 5-7 krotne przyspieszenie weryfikacji na sprzęcie x86_64 pozwoli na łatwiejsze podłączanie nowych węzłów oraz zmniejszy obciążenie na już działających

– OP_CHECKSEQUENCEVERIFY – 25x zwiększenie efektywności działania kanałów płatności wzajemnych przez umożliwienie trzymania kanału płatności otwartego tak długo, jak jest to potrzebne

– bity wersji (BIP9) – umożliwienie wdrażania jednocześnie nie jednego a maksymalnie 29 softforków, pozwalając na szybsze i bardziej zdecentralizowane głosowanie kolejnych zmian

– segregated witness – bezpośrednie zwiększenie przepustowości o 175 do 400%, dalsze 66% zwiększenie wydajności dwukierunkowych kanałów płatniczych przez łączenie operacji otwierania i zamykania kanałów, uniemożliwienie modyfikacji transakcji „smart contracts”, umożliwienie „lekkim klientom” na wspomaganie pracy całej sieci, umożliwienie rozwinięcia języka skryptowego Bitcoin w kierunku budowania nowych bezpiecznych kontraktów nie wymagających trzeciej strony (trustless contracts).

– IBLT oraz „cienkie” bloki – zmniejszenie o 90% (lub więcej) zapotrzebowania na przepustowość przy przesyłaniu nowego bloku z kopalni i pomiędzy węzłami, zwiększenie przepustowości sieci bez zwiększania ilości przesyłanych danych,znacznie zmniejszenie czasu propagacji nowych bloków, zwiększenie wpływu węzłów przekazujących na działanie sieci. Wdrożenie tech technologi pozwoli w przyszłości bezpiecznie zwiększać maksymalny rozmiar bloków nie powodując znacznych obciążeń po stronie kopalni oraz węzłów Core.

2. Czy wprowadzenie SW jest równoznaczne ze zwiększeniem maksymalnej wielkości bloku do 4, 2 czy 1.75MB?

Aktualna wersja propozycji SW pozwala na zapisanie 4 bajtów poza blokiem na każdy bajt w bloku, czyli jest to odpowiednik 4MB bloku. Jednakże nie każda transakcja pozwala się zapisać identycznie w ten sposób, więc bloki wielkości 4MB są mało prawdopodobne.

Obliczenia przeprowadzone przez Anthonego Townsa pokazują, że blok zapełniony standardowymi transakcjami P2PKH daje pojemność około 1.6MB, zaś blok transakcji miltisig 2-z-2 będzie miał pojemność około 2.0MB.

3. SW jest skomplikowane, czy sieć i użytkownicy są gotowi na jej wdrożenie?

Niektóre idee są łatwe do opisania a trudne do wykonania. Inne są łatwe do wykonania a trudne do wytłumaczenia. SW wydaje się być tym drugim.

SW może być wdrożone bez utraty wstecznej kompatybilności, więc nie są potrzebne żadne zmiany w sieci. Deweloperzy którzy chcą sprawdzić działanie SW na żywo będą mogli to robić w uruchomionej sieci testowej SW.

Na początku tylko kopalnie będą musiały wdrożyć wymagane zmiany. Istniejące aplikacje będą musiały być zmodyfikowane tylko, jeżeli będą chciały korzystać z nowych funkcji.

Transakcje SW będą mogły mieć niższe opłaty, spowodują znaczne zwiększenie wydajności węzłów sieci oraz mogą wspierać „smart contracts” oraz protokoły takie jak dwukierunkowe kanały płatności które mogą być skalowane bez zapisu dodatkowych danych do bloku. Zalecana jest aktualizacja portfeli, ale mogą one dalej działać bez żadnych zmian dzięki zachowaniu kompatybilności wstecznej.

4. SW nadal wydaje się skomplikowane, dlaczego po prostu nie zwiększyć maksymalnej wielkości bloku?

Tylko jedna linia kodu w źródłach Bitcoin Core decyduje o maksymalnej wielkości bloku. Najprostsza modyfikacja to hardfork ze zmianą do na przykład 2MB.

Hardforki jednak nie są proste:

• nie mamy doświadczenia – kopalnie, handlowcy, deweloperzy ani użytkownicy nigdy nie wdrażali hardforka, więc nie przetestowano dotąd bezpiecznej metody ich wdrażania. Softforki przeciwnie, były wdrażanie wielokrotnie, pierwotnie pod okiem Nakamoto (BIP16), aktualnie przez używanie BIP34 i wprowadzenie BIP66, 65 a obecnie wdrażany BIP9 który umożliwi wdrażanie wielu softforków w tym samym czasie.

• wymagana aktualizacja – hardfork wymaga aby wszystkie pełne węzły sieci zostały zaktualizowane. Ten, kto używa nieaktualnego węzła naraża się nawet na utratę środków. Wymaga też aktualizacji wszystkich portfeli włączenie z „lekkimi” które pobierają dane z pełnych węzłów.

• wymaga więcej zmian – nawet zmiana jednej linii w kodzie powoduje zmiany w działaniu innych części kodu które mogą nie być pożądane. Na przykład, obecnie jest możliwe zbudowanie transakcji która będzie miała 1MB wielkości, i jej weryfikacja zajmie około 30 sekund na nowoczesnym komputerze. Przy bloku 2MB, transakcja takiej wielkości będzie wymagała aż 10 minut na weryfikację, co otwiera nowy rodzaj ataków na sieć. Inne części kodu będą musiały być zmienione aby uniknąć takich problemów.

Pomijając ewentualne problemy, zachowując duża ostrożność, wprowadzenie hardforka jest możliwe i przewidujemy, że wprowadzenie takowych będzie konieczne. Ale wprowadzenie zmiany SW jako softfork jest rozwiązaniem które znamy i umiemy bezpiecznie wdrażać w sieci, pozwala też na jednoczesne wprowadzenie wielu innych udogodnień oprócz zwiększenia ilości transakcji jakie mogą zostać dodane do bloku.

SW wymaga wprowadzenia wielu różnych zmian w kodzie niż proste zwiększenie wielkości bloku. Jeżeli jednak chcemy aby Bitcoin dawał się skalować w przyszłości to wprowadzenie drastycznych zmian w kodzie będzie nieuniknione. SW pozwala nam delikatnie popchnąć użytkowników w kierunku aktualizacji do bardziej skalowalnej wersji bez zmuszania ich do tego.

Wszyscy mamy znacznie większe doświadczenie we wprowadzaniu softforków. Wierzymy, że SW może być wdrożone jako softfork równie szybko i prawdopodobne bardziej bezpiecznie niż hardfork zwiększający maksymalną wielkość bloku.

5. Czy hardfork będzie musiał być wprowadzony przed SW lub będzie częścią jego wdrożenia?

Nie, nie jest to konieczne ani planowane.

6. Skoro hardfork jest nieunikniony, to dlaczego nie zrobić go teraz?

 

Istnieje obecnie sposób na zwiększenie przepustowości sieci za pomocą softforka, który ma szerokie poparcie w społeczności i nie powoduje tylu komplikacji co hardfork (jak pisaliśmy we wcześniejszym pytaniu). To, że hadfork jest nieunikniony nie jest wystarczającym powodem, aby wprowadzać go teraz.

W usprawnienia jakie proponujemy (włączając w to np. kanały płatności dwukierunkowej), dajemy użytkownikom możliwość zmniejszenia średniej ilości danych zapisywanych do łańcucha bloków – efektywnie zwiększając pojemność systemu Bitcoina bez zwiększania ilości danych przesyłanych pomiędzy pełnymi węzłami.

Na przykład:

• BIP68 i BIP112 pozwalają na pozostawienie kanału płatności dwukierunkowej otwartego w nieskończoność co, jak oczekujemy, znacznie zmniejszy ilość danych transakcyjnych jakie muszą zostać zapisane w łańcuchu bloków.

• oddzielenie podpisów („segregated witness”, SW) pozwala na zakończenie jednego kanału płatności z jednoczesnym otwarciem kolejnego kanału, zmniejszając ilość danych zapisywanych do bloku o około 66%.

• SW pozwala na softforki zmieniające język skryptowy Bitcoin ( Bitcoin Script language) w sposób, który zmniejszy średni rozmiar transakcji, na przykład na wydobywanie kluczy publicznych z podpisów (public-key-recovery-from-signatures) lub podpisy łączone Schnorra (Schnorr combined signatures)

• SW pozwala na stworzenie skompresowanych dowodów wydania (compact fraud proofs) które zwiększą bezpieczeństwo klientów SPV („lekkich” portfeli) na poziom porównywalny z pełnymi węzłami, umożliwi to działanie sieci nawet z mniejszą ilością pełnych węzłów niż dotychczas.

Nie jesteśmy w stanie określić dokładnie efektów, jakie przyniosą te technologie, ale zwieszenie skalowalności przez wprowadzenie softforka (który ma poparcie społeczności) daje nam natychmiastowe efekty, pozwala na testowanie i pomiar skutków kolejnych zmian, i użycie uzyskanych danych do sformułowania kolejnych, długoterminowych, planów.

7. Jak transakcje SW będą działały w portfelach?

 

Portfele, które aktualnie wspierają P2SH (Pay-to-script-hash) mogą migrować do pełnej implementacji oddzielenia podpisów w dwóch krokach:

• krok 1: skrypty są haszowane dwukrotnie, najpierw do 256 bitów a następnie do 160 bitów. 160. bitowy hasz będzie kompatybilny z obecnymi adresami P2SH, więc zaktualizowane portfele będą mogły wysyłać i otrzymywać monety z obecnie działającymi portfelami.

• krok 2: skrypty są haszowane jednorazowo do 256 bitów. Ten format nie będzie zgodny z istniejącymi portfelami, ale pozwoli na znacznie efektywniejsze użycie miejsca w bloku i oferuje większe bezpieczeństwo ze względu na większą odporność na kolizje.

8. Jeżeli nikt nie zmusza do aktualizacji, czy ktokolwiek będzie chciał aktualizować? Powszechne używanie P2SH zajęło prawie dwa lata.

 

Każdy bajt transakcji SW będzie liczony jako tylko 0.25 bajta wielkości transakcji. Ponieważ opłata transakcyjna jest liczona od wielkości transakcji, daje to 75% zniżkę na opłatę za transakcję – ale tylko dla ludzi, którzy użyją formatu SW transakcji.

David Harding opracował tabelę szacowanych oszczędności dla różnych poziomów opłat/typów transakcji. W przypadku typowej 250-bajtowej transakcji opłata wynosi około $0.01, to używając SW pozwoli zaoszczędzić $0.003 gdy użyjemy wyjścia typu P2PK-w-P2SH.

Transaction	Bytes saved	$0.01/250B	$0.05/250B	$0.25/250B	$1.00/250B
P2PK-in-P2SH	79/107	$0.003	$0.015	$0.079	$0.316
1-of-1 P2SH multisig	83/112	$0.003	$0.016	$0.083	$0.332
2-of-2 P2SH multisig	163/219	$0.006	$0.032	$0.163	$0.652
2-of-3 P2SH multisig	189/254	$0.007	$0.037	$0.189	$0.756

 

(nie oczekujemy tak wysokich opłat transakcyjnych jak przedstawione w tabeli, są podane tylko jako punkt odniesienia)

Portfele online i giełdy które codziennie wysyłają duża ilość transakcji ze stałą opłatą (na przykład opłata w wysokości 1% wydania) będą mogły zaoszczędzić znaczne ilości monet, w wyniku kumulowania się małych oszczędności przy każdej transakcji.

9. Słyszałem, że uniemożliwiacie akceptowanie transakcji bez potwierdzeń, która z proponowanych technologii to powoduje?

 

Żadna z nich. Domyślnie, obecne wersje Bitcoin Core nie podmieniają niepotwierdzonej transakcji która wydaje te same wejścia. Niektórzy ludzie myślą, że transakcja którą otrzymają jako pierwszą jest bezpieczna, ale to nie jest prawda (gdyby była to prawda, nie potrzebowalibyśmy łańcucha bloków).

Obecne domyślne zachowanie oznacza, że ludzie którzy chcą zaktualizować swoją niepotwierdzoną transakcję nie mogą tego zrobić. Oryginalna wersja Bitcoin Core pozwalała ludziom na oznaczanie transakcji jako możliwe do aktualizacji, ale Nakamoto musiał wyłączyć tą funkcję w 2010 roku aby uniknąć ataków DoS na sieć (atakujący mógł w nieskończoność aktualizować transakcję i zatykać sieć bez ponoszenia kosztów).

Ostatnio deweloperzy Core uzmysłowili sobie, że można unikną tego typu ataków jeżeli zmodyfikowana transakcja będzie wymagała dodatkowej opłaty, i uruchomili mechanizm Nakamoto który umożliwia zaznaczenie, że transakcja może zostać zaktualizowana.

Funkcjonalność ta jest planowana w Core v0.12.0 (~styczeń/luty 2016), ale będzie wymagała ona aktualizacji portfeli, jeżeli użytkownicy będą chcieli tej funkcji używać.

Obecnie nie ma żadnego portfela który udostępnia tą funkcję, ale portfele które będą jej używać w przyszłości będą miały możliwość łączenia wielu transakcji w jedną w celu zmniejszenia całkowitej wielkości transakcji zapisywanej do łańcucha bloków. Będą też mogły zwiększyć opłatę transakcji która długo nie jest potwierdzana, unikając sytuacji jej „utknięcia” w kolejce (co jest znanym problemem).

10. Lekkie bloki i IBLT są opisane jako „2016” w terminarzu, czy oznacza to, że nie wiecie kiedy będą wdrożone?

 

Są to dwie technologie które są aktualnie analizowane w celu wybrania najlepszych parametrów działania, ale ilość deweloperów nad tym pracujących jest ograniczona, ciężko jest więc określić kiedy będą one wdrażane.

Obie te technologie mogą być wdrożone jako ulepszenia działania sieci (nie jest wymagany soft- ani hard-fork), oznacza to że będzie bardzo krótki czas pomiędzy wdrożeniem a używaniem przez zaktualizowane węzły sieci. Mamy nadzieję, że stanie się to w 2016 roku.

Po wdrożeniu, lekkie bloki i IBLT będą mogły czerpać korzyści z kolejnego softforka wprowadzone przez BIP9 – kanonicznej kolejności transakcji w bloku.

11. Dlaczego kopalnie miałby by przyjąć format SW, jeżeli nie daje on im żadnych oszczędności w ilości przesyłanych danych, mocy obliczeniowej czy ilości danych na dysku?

 

Większość poprzednich softforków również nie dawało górnikom korzyści (BIP16, 30, 34, 65).

BIP66 aktywowany w lipcu 2015 już wkrótce będzie miał znaczny wpływ na zmniejszenie zapotrzebowania na moc obliczeniową dzięki przejściu na libsecp256k1 (opisane wcześniej w FAQ). Zmniejszenie czasu weryfikacji sprawia że jest to wyjątkowa zmiana pośród softforków, bo daje bezpośrednie korzyści górnikom.

Wprowadzenie SW daje kilka ważnych zmian, ważnych dla każdego kto użyje go do budowania transakcji:

• całkowita odporność na modyfikowanie transakcji (third-party malleability) co pozwoli na rozkwit wielostopniowych kontraktów (multi-stage smart contracts)
• zmniejszenie opłat transakcyjnych
• łatwe aktualizowanie skryptów Bitcoin i zwiększanie możliwości jakie dają transakcje.

Zarówno poprzednie softforki jaki i „panel górników” na konferencji SBHK pokazał, że górnikom zależy na jak największym zwiększeniu użyteczności Bictoina, nawet jeżeli nie oznacza to dla nich bezpośrednich korzyści. SW i kolejne zaplanowane ulepszenia znacząco zwiększają użyteczność sieci Bitcoin.

Dodatkowo SW pozwala na dołączenie do bloku większej ilości transakcji, co może im dać zwiększenie korzyści z wydobycia bloku (większa ilość/łączna wartość opłat).

12. Jak mogę pomóc?

Rozpocznij od przeczytania stron „Bitcoin Core contributor” na bitcoin.org. Szczególnie weryfikacja kodu jest krytyczną częścią wdrażania softforków.

Zapraszamy na kana IRC #bitcoin-dev po szczegółowe instrukcje/wytyczne.

Tłumaczenie Capacity increases FAQ

Fotografia na licencji Creative Commons: Flickr.com