BitcoinXT: Alernatywny protokół przesyłania bloku

[McGravier]

Mike Hearn testuje obecnie protokół tzw. "chudych bloków"

Idea sama w sobie jest banalna - Zamiast przesyłać cały blok klient wysyła jedynie sumy kontrolne - otrzymujący z kolei wynajduje transakcje pasujące do hashy ze swojego bufora niepotwierdzonych transakcji. W przypadku braku transakcji w buforze zostają one pobrane od innych peerów

Jest to pierwszy etap rozwojowy w kierunku IBLT zaproponowanego przez Gavina Andersena polegający na przesyłaniu bloków poprzez synchronizację kolejki.

Wedle słów autora nowy protokół jest wolniejszy przy pierwotnej synchronizacji i przy przesyłaniu pustych bloków. W przypadku dużych bloków otrzymywanych na bieżąco teoretycznie redukuje ilość przesłanych danych nawet 14x

Rozwiązanie jest w fazie testów. Nie ma obecnie żadnej zapowiedzi umieszczenia go w kliencie Core

Oryginał ogłoszenia tutaj
https://groups.google.com/forum/#!topic ... nX-pRQ46OU

[ShadowOfHarbringer]

Link do tematu na reddicie:


Generalnie koncepcja absolutnie genialna. Jeżeli to by zadziałało, suma pobieranych danych zmniejszyłaby się 10x (a dokładnie to 14 razy) i cały problem dużych bloków oraz kontrowersji zostałby rozwiązany raz na zawsze.

Ba ! Przy użyciu tego nowego protokołu, Bitcoinem cały świat mógłby płacić za codzienne bułki i masło i nie spowodowałoby to przeciążenia sieci.

Genialne.

EDIT:
OK, jednak trochę się przejechałem, maksymalna poprawa całkowitego potrzebnego transferu to jakieś ~50% (bo dochodzi jeszcze osobne pobieranie transakcji przez klienty). Ale i tak jest to duży postęp.

[McGravier]

Ogólny problem z rozmiarem bloku jest taki, że średnio co 10 minut występuje chwilowe koszmarnie wysokie zapotrzebowanie na przepustowość - to powoduje, że wymagane są łącza nieproporcjonalnie szybkie w stosunku do średniego zapotrzebowania. Aby nawiązać walkę z VISĄ wymagane są bloki o rozmiarach ~1GB i łącza >1Gbps.

Dzięki rozwiązaniu Mikea ten sam rozmiar bloku może być sprawnie obsłużony przez łącza o przepustowości rzędu 100Mbps. To kolosalna różnica - to przybliża nas o całe lata do docelowej ilości transakcji na sekundę

[ShadowOfHarbringer]

Ogólny problem z rozmiarem bloku jest taki, że średnio co 10 minut występuje chwilowe koszmarnie wysokie zapotrzebowanie na przepustowość - to powoduje, że wymagane są łącza nieproporcjonalnie szybkie w stosunku do średniego zapotrzebowania. Aby nawiązać walkę z VISĄ wymagane są bloki o rozmiarach ~1GB i łącza >1Gbps.

Dzięki rozwiązaniu Mikea ten sam rozmiar bloku może być sprawnie obsłużony przez łącza o przepustowości rzędu 100Mbps. To kolosalna różnica - to przybliża nas o całe lata do docelowej ilości transakcji na sekundę

Yep. Rozmiar samego bloku jest 14 razy mniejszy, więc nie ma tak dużego skoku przy nagłym pobieraniu nowego bloku przez całą sieć.

To jest kosmos i totalnie, absolutnie zmienia zasady gry. Bitcoin może teraz bezproblemowo stać się walutą globalną i być z powodzeniem używany do kupowania w biedronce.

[Bitmar]

Temat trafił też na http://bitcoin.pl/wiadomosci/techniczne ... ow-w-sieci

[powered]

Ale czy kwestia maksymalnej wielkości bloku została w tym przypadku rozwiązana?
Z tego co rozumiem to węzły pomiędzy sobą będą rozsyłać tylko nagłówek bloku i na podstawie tego nagłówka zbudują (odtworzą) poprawny blok w swojej bazie łańcuchów bloków. Czyli docelowo wielkość bloku nie ulega zmianie?

[Bitmar]

Sama koncepcja "cienkich bloków" nie rozwiązuje problemu wielkości bloków. Samo XT rozwiązuje, ale w inny sposób o którym była mowa http://bitcoin.pl/wiadomosci/techniczne ... iaru-bloku

[ShadowOfHarbringer]

Ale czy kwestia maksymalnej wielkości bloku została w tym przypadku rozwiązana?
Z tego co rozumiem to węzły pomiędzy sobą będą rozsyłać tylko nagłówek bloku i na podstawie tego nagłówka zbudują (odtworzą) poprawny blok w swojej bazie łańcuchów bloków. Czyli docelowo wielkość bloku nie ulega zmianie?

Wielkość bloku nie ulegnie zmianie (w sensie zostanie na 8MB zgodnie z BIP101), aczkolwiek szybkość jego pobierania tak.
Dodatkowo nastąpi "wygładzenie" wszystkich skoków transferu.

Spowoduje to bezpośrednio, że każdy będzie mógł na swoim domowym łączu 1Gbit (w ~2030) trzymać uruchomionego full node'a nawet gdy Bitcoin będzie miał więcej transakcji na sekundę niż VISA.

(Oczywiście nie podaję, że pewnie będzie potrzebny dysk 100TB w RAIDzie na przechowywanie łańcucha bloków, to chyba oczywiste)

[majkel_94]

Hola hola... mniej danych jest przy rozsyłaniu bloku, dlatego bardzo dużo zyska znalazca bloku bo wszystkim roześle znacznie mniej danych.

Ale pozostałe węzły zakładając, że mają wszystkie transakcje, to nie dostaną ich drugi raz... więc w ich przypadku zysk będzie tylko 2x.

Potrzeba chyba więcej szczegółów i testów, by skalkulować dokładnie ile to łącza średnio zaoszczędzi

[ShadowOfHarbringer]

Hola hola... mniej danych jest przy rozsyłaniu bloku, dlatego bardzo dużo zyska znalazca bloku bo wszystkim roześle znacznie mniej danych.

Ale pozostałe węzły zakładając, że mają wszystkie transakcje, to nie dostaną ich drugi raz... więc w ich przypadku zysk będzie tylko 2x.

Przecież dokładnie to samo napisałem powyżej...

[rav3n_pl]

Przy założeniu, że wszyscy mają ten patch, każdy węzeł przekazujący "dalej" nowy blok ma wielkie oszczędności.
Pobrać blok musi tylko raz, ale rozesłać go dalej może do wszystkich podłączonych do siebie węzłów.
Biorąc takie explorery które mają po 1000+ połączeń, oszczędności w wysyłanych danych będą ogromne.

[majkel_94]

Czyli dany wezel mimo ze ma juz blok to i tak go dostaje od wszystkich podlaczonych do niego wezlow?

[rav3n_pl]

Nie.
Nie jest to wysyłane na siłę.
Jest komunikat "dostałem nowy blok xxxx, chcesz?" i jeżeli pada odpowiedź "dawaj!" to leci 1MB danych.