Compact Blocks

Anna chce wysłać Piotrowi nowy blok, ale Piotr ma już wiele zawartych w nim transakcji. Blok grupuje transakcje w pakiet dołączany do wspólnej historii. Wysłanie wszystkich powtórzyłoby dane. Mechanizm Compact Blocks przekazuje więc nagłówek i listę krótkich oznaczeń pozwalających odnaleźć znane transakcje. Nagłówek to krótka część bloku z podstawowymi danymi, w tym odwołaniem do poprzedniego bloku i odciskiem kontrolnym transakcji. Dla zainteresowanych techniką: oznaczenia mają 48 bitów, czyli 6 bajtów, i powstają przez skrócenie wyniku funkcji SipHash-2-4. Jej parametry wynikają z nagłówka oraz dodatkowej liczby dla tego przesyłania, zwanej nonce. Oznaczenie nie jest zatem trwałą nazwą transakcji dla całej sieci Bitcoin. [1] [2] [7]

Nie wszystko da się zastąpić listą. Anna wysyła wybrane transakcje w całości wraz z pozycją w bloku. Typowy przykład to Coinbase Transaction, pierwsza transakcja bloku przydzielająca nagrodę za wydobycie; nie ma związku z giełdą o tej samej nazwie. Powstaje specjalnie dla tego bloku, więc Piotr zazwyczaj nie ma jej wśród oczekujących transakcji. Pełne wpisy i krótkie oznaczenia uzupełniają się przy odtwarzaniu. [1] [2]

Mempool Piotra to lokalny zbiór transakcji znanych jego węzłowi, lecz jeszcze niepotwierdzonych w przyjętym łańcuchu. Dla dostępnych transakcji oblicza takie same krótkie oznaczenia i szuka zgodności z listą Anny. Nie zakłada, że wszyscy mają identyczny zbiór. Ponieważ oznaczenie może czasem odpowiadać kilku transakcjom, samo dopasowanie nie jest ostatecznym dowodem poprawnej treści. [1] [2]

Jeśli pozycje pozostają puste lub niejednoznaczne, Piotr prosi o konkretne transakcje według ich pozycji. Żądanie nazywa się getblocktxn, a odpowiedź z transakcjami blocktxn. Nie trzeba zapamiętywać tych nazw: ważne, że pobiera się prawdziwe dane zamiast zgadywać treść. Dodatkowy obieg żądania i odpowiedzi zabiera czas. Jeśli odtworzenie się nie uda, można pobrać cały blok. [1] [3]

Piotr musi odzyskać dokładne transakcje we właściwej kolejności i sprawdzić ich powiązanie z nagłówkiem. Merkle Tree łączy transakcje w odcisk kontrolny pomagający zweryfikować to powiązanie. Prawidłowe złożenie nie zastępuje jednak kontroli reguł. Full Node to program, za pomocą którego Piotr samodzielnie sprawdza reguły Bitcoina, na przykład uprawnienie do wydania środków i wysokość nagrody. Podpis cyfrowy potwierdza autoryzację płatności za pomocą klucza prywatnego, czyli tajnej wartości liczbowej, bez ujawniania tego klucza. Przesyłanie kompaktowe nie daje wyjątku dla nieprawidłowego bloku. [1] [8]

Sąsiednie węzły uzgadniają tryb komunikatem sendcmpct. W szybkim wariancie cmpctblock z danymi do odtworzenia od razu ogłasza nowy blok. Po wymaganych kontrolach wstępnych nadawca może rozpocząć wysyłanie przed zakończeniem wszystkich kontroli transakcji. Musi sprawdzić między innymi połączenie ze zweryfikowanym łańcuchem, Proof of Work jako dowód pracy obliczeniowej oraz powiązanie nagłówka z transakcjami. Odbiorca nadal w pełni weryfikuje blok przed przyjęciem do swojej historii. [1] [4]

Drugi wariant najpierw ogłasza już zweryfikowany blok przez inv lub headers. Piotr prosi wtedy o dane kompaktowe, jeśli ich potrzebuje. Może uniknąć zbędnego pobrania bloku otrzymanego inną drogą, płacąc za to dodatkowym krokiem komunikacji. Oba tryby mogą oszczędzać dane względem ponownego wysłania wszystkich transakcji. Różnią się momentem wysyłki i potrzebą wcześniejszego żądania, a nie poziomem poprawności bloku. [1] [7]

Dwie różne transakcje mogą mieć takie samo krótkie oznaczenie. Nazywamy to kolizją. Jak przy dwóch osobach o tych samych inicjałach, skrót nie wystarcza do rozróżnienia. Zależnie od miejsca problemu program prosi o dodatkowe dane lub pobiera cały blok. Kolizja nie łamie podpisów Bitcoin i nie zmienia nieprawidłowego bloku w prawidłowy. Trzeba sprawdzić rzeczywistą treść, nie tylko zgodność krótkich oznaczeń. [1] [2]

Wersja 2 protokołu kompaktowego obsługuje SegWit, który oddziela podpisy i inne dane weryfikacyjne do części witness. Używa wtxid, identyfikatora uwzględniającego te dane, zamiast txid, który ich nie obejmuje. Pełne transakcje są przesyłane z wymaganymi danymi witness według BIP 144. Nie odrzuca się ich, aby przesyłka wyglądała na mniejszą. Wersja protokołu przesyłania nie jest też numerem wersji samego bloku. [1] [6]

Jeśli Anna i Piotr znają wiele wspólnych transakcji, nowy blok dociera z dużo mniejszą ilością powtarzanych danych. Pomaga to także domowemu łączu przy nagłym nadejściu bloku. Przy małym pokryciu zbiorów rośnie liczba dodatkowych żądań i oszczędność spada. Główny cel to mniej przesyłanych danych; szybsze dostarczenie jest możliwą korzyścią, nie gwarancją zerowego oczekiwania ani stałego rozmiaru wiadomości. Bitcoin nie otrzymuje przez to nowego limitu rozmiaru bloków. [5] [7]