Artykuł autorstwa Pana Michaela Nielsena. Tłumaczenie własne, za zgodą Pana Michaela Nielsena. Pierwotnie esej został opublikowany 6 grudnia 2013 roku w Internecie pod adresem http://www.michaelnielsen.org/ddi/how-the-bitcoin-protocol-actually-works/. Artykuł został przez Bruce'a Schneiera skomentowany tymi słowami:

To najlepszy opis protokołu Bitcoin jaki do tej pory przeczytałem.

Tłumaczenie może zawierać błędy. Jeśli tak jest, to bardzo przepraszam i proszę o zwrócenie mi na nie uwagi, wtedy je poprawię. Zwrócić uwagę można m.in. poprzez ten wątek. Jednocześnie oświadczam, że nie biorę żadnej odpowiedzialności za informacje zawarte w tym artykule. Informacji tych używasz na własne ryzyko.

Życzę miłego czytanie jednego z najobszerniejszych artykułów w języku polskim poświęconych tematowi jak działa Bitcoin. Mam nadzieję, że zdobyta wiedza pozwoli bezpieczniej i efektywniej wykorzystywać tę internetową kryptowalutę, dzięki zrozumieniu czym jest Bitcoin.

Opis działania obecnej wersji protokołu sieci Bitcoin.

• Oryginalny tytuł: How the Bitcoin protocol actually works
• Autor: Michael Nielsen
• Tłumaczenie: uzytkownikubunt

Wiele tysięcy artykułów zostało napisanych w celu wyjaśnienia, czym jest Bitcoin, Internetowa, działająca w oparciu o sieć rozproszoną, waluta. Większość z tych artykułów daje ogólnikowy opis działania protokołu kryptograficznego, omijając wiele szczegółów. Nawet te artykuły, które drążą temat głębiej często omijają bardzo ważne szczegóły. Moim celem w tym artykule jest wyjaśnienie głównych idei stojących za protokołem Bitcoin w sposób jasny, łatwy, wyczerpujący temat. Zaczniemy od ogólnych zasad, budując szerokie teoretyczne zrozumienia jak działa protokół, a następnie zaczniemy zagłębiać się w konkretne detale, rozpatrując surowe dane transakcji Bitcoin.

Zrozumienie protokołu w ten szczegółowy sposób jest ciężką pracą. Kusi, by po prostu używać Bitcoina, i zastanawiać się jak stać się dzięki niemu bogatym, czy Bitcoin jest bańką spekulacyjną, czy Bitcoin pewnego dnia pozwoli pewnego dnia uwolnić ludzi od podatków, i tak dalej. Jest to przyjemne, ale mocno ogranicza Twoje zrozumienie. Zrozumienie szczegółów protokołu Bitcoin otwiera, z dotychczasową wiedzą niedostępne, nowe horyzonty. W szczególności, to podstawa dla zrozumienia wbudowanego języka skryptowego, który pozwala używać Bitcoina by tworzyć nowe typy instrumentów finansowych, takich jak smart contracts. Te z kolei mogą zostać użyte do tworzenia nowych rynków i otworzyć drogę do dalszych form kolektywnego zachowania. Porozmawiajmy o ciekawych zagadnieniach!

Język skryptowy w Bitcoinie i koncepcje jak „smart contracts” opiszę w przyszłych wpisach. Ten wpis koncentruje się na wyjaśnianiu niezbędnych szczegółów/podstaw działania protokołu Bitcoin. By zrozumieć ten wpis, musisz już posiadać wiedzę z zakresu kryptografii klucza publicznego, i powiązanej idei cyfrowego podpisu. Założę również, że znasz temat kryptograficznych funkcji skrótu. Nic z powyższych nie jest specjalnie trudne. Podstawowe idee mogą być nauczane w nauczane w kursach dla świeżaków przygotowujących do podjęcia studiów z dziedzin wiedzy takich jak matematyka czy informatyka. Pomysły te są piękno, więc jeśli nie jesteś z nimi zapoznany, rekomenduję przeznaczyć kilka godzin by się z nimi zapoznać.

To może wydawać się zaskakujące, że podstawy Bitcoina opierają się na kryptografii. Czyż nie jest Bitcoin walutą, a nie sposobem wysyłania tajnych wiadomości? Fakt jest taki, że problemy konieczne do rozwiązania przez protokół polegają na zabezpieczaniu transakcji – zapewnieniu, że ludzie nie mogą kraść od innych, podszywać się pod innych i tak dalej. W świecie materii z atomów utrzymujemy bezpieczeństwo przez urządzenia jak zamki, sejfy, sygnatury i skrytki/depozyty w bankach. W świecie bitów utrzymujemy ten rodzaj bezpieczeństwa dzięki kryptografii. I to jest powód, dla którego Bitcoin jest w swoim rdzeniu protokołem kryptograficznym.

Moją strategią w tym wpisie jest zbudowanie Bitcoina krok po kroku. Rozpocznę od wyjaśnienia bardzo prostej cyfrowej waluty, opartej na oczywistych pomysłach. Będziemy nazywać tą walutę Infocoin, by odróżnić ją od Bitcoina. Oczywiście, nasza pierwsza wersja Infocoina będzie miała wiele braków, więc będziemy przechodzili poprzez kolejne fazy rozwoju Infocoina, z każdą fazą wprowadzając jeden lub dwa nowe, proste pomysły. Po wielu takich fazach, otrzymamy protokół Bitcoin. Otrzymamy wymyślonego na nowo Bitcoina! Ta strategia jest wolniejsza niż gdybym wyjaśnił cały protokół Bitcoin od razu. Ale podczas, gdy Ty mógłbyś zrozumieć mechanikę Bitcoina w jednostkowym wyjaśnieniu, byłoby ciężko zrozumieć, dlaczego Bitcoin jest zaprojektowany w ten sposób. Zaletą wolniejszego, wielokrokowego podejścia w wyjaśnianiu jest to, że daje zdecydowanie mocniejsze zrozumienie każdego elementu Bitcoina.

Ostatecznie, powinienem wspomnieć, że jestem relatywnym nowicjuszem, jeżeli chodzi o Bitcoin. Śledziłem Bitcoin od 2011 (i kryptowaluty od późnych lat 90 ubiegłego wieku), ale poważne szczegóły protokołu zacząłem analizować na początku tego roku. Więc pragnę powiedzieć, że będę cenić wszystkie korekcje jakichkolwiek błędów z mojej strony. We wpisie również zawarłem pewną liczbę „problemów dla autora” – notatki dla siebie na temat pytań, które naszły mnie podczas pisania. Być może będą dla Ciebie ciekawe, ale równie dobrze możesz je pominąć całkowicie bez tracenia wątku głównego tekstu.

Pierwszy krok: podpisany list-zlecenie

Więc jak możemy zaprojektować cyfrową walutę?

Wstępnie, cyfrowa waluta brzmi niemożliwie. Przyjmijmy, że pewna osoba – nazwijmy ją Ala – ma pewną cyfrową walutę, którą chce wydać. Jeżeli Ala może użyć ciągu bitów, jako pieniędzy, jak możemy zapobiec by nie mogła używać tego samego ciągu znaków kolejny i kolejny raz, tak jakby posiadała nieskończone źródło pieniędzy? Albo, jeżeli możemy w jakiś sposób rozwiązać ten problem, jak możemy zapobiec by ktokolwiek inny nie mógł podrobić takiego ciągu bitów, i używać go by kraść od Ali?

To tylko dwa z wielu problemów, z którymi musimy sobie poradzić by używać informacji jako pieniędzy.

W pierwszej wersji Infocoina, spróbujmy znaleźć metodę, by Ala mogła używać ciągu bitów, jako (bardzo uproszczoną i niekompletną) formę waluty, w sposób w który daje jej przynajmniej minimalną ochronę przeciwko podrabianiu i kradzieży jej pieniędzy. Przyjmijmy, że Ala chce podarować innej osobie, Bobowi, infocoina. By tego dokonać, Ala pisze wiadomość „Ja, Ala, przyznaję Bobowi jeden infocoin”. Następnie dokonuje cyfrowego podpisu wiadomości używając prywatnego klucza kryptograficznego, i obwieszcza podpisany ciąg bitów całemu światu.

(Przy okazji, używam słowa Infocoin pisanego z wielkiej litery by nawiązać do protokołu i generalnej koncepcji, a słowa pisanego małymi literami „infocoin” by nawiązać do konkretnej porcji waluty (tak jak do konkretnego banknotu). Zwykle podobna konwencja, choć nie zawsze, występuje w świecie Bitcoina.)

To nie jest szczególnie wymyślna cyfrowa waluta! Ale posiada pewne zalety. Każdy w świecie (łącznie z Bobem) może użyć klucza publicznego Ali by zweryfikować czy rzeczywiście to Ala była osobą, która napisała wiadomość „Ja, Ala, przyznaję Bobowi jeden infocoin”. Nikt inny nie mógł stworzyć takiego ciągu bitów, więc Ala nie mogła później zaprzeczyć mówiąc: „Nie, I nie przyznałam Bobowi infocoina”. Więc protokół pozwala na ustalenie, że Ala naprawdę oświadczyła przyznanie Bobowi jednego infocoina. Ten sam fakt – nikt inny nie mógł stworzyć tak podpisanej wiadomości – również pozwala ustanowić dla Ali ograniczoną ochronę przed kradzieżą. Oczywiście, po tym jak Ala opublikowała jej wiadomość, dla innych osób staje się możliwe by duplikować wiadomość, więc w tym sensie kradzież jest możliwa. Ale nie jest możliwe to od początku. Te dwie własności – pozwolenie na ustalenie czy Ala rzeczywiście przyznała infocoiny, i ograniczona ochrona przed kradzieżą – są naprawdę znaczącymi właściwościami jego protokołu.

Nie powiedziałem (nie zupełnie), czym w ogóle są cyfrowe pieniądze. By napisać to wyraźnie: To wiadomości same w sobie, na przykład ciąg bitów reprezentujący cyfrowo podpisaną wiadomość „Ja, Ala, przyznaję Bobowi jeden infocoin”. Późniejsze protokoły będą podobne, w każdej następnej formie naszej cyfrowej waluty będą po prostu bardziej i bardziej złożone wiadomości [1].

Używanie numerów seryjnych by uczynić monety jednoznacznie identyfikowalne

Problem z pierwszą wersją Infocoina jest taki, że Ala może po prostu wysyłać Bobowi ciągle ten sam ciąg bitów. Przyjmijmy, że Bob odbiera 10 kopii podpisanych wiadomości „Ja, Ala, przyznaję Bobowi jeden infocoin”. Czy to oznacza, że Ala wysłał dziesięć różnych infocoinów? Czy może jej wiadomość została przypadkowo zduplikowana? Być może Ala próbowała oszukać Boba, by ten uwierzył, iż ona przyznała mu dziesięć różnych infocoinów, podczas gdy wiadomość udowadniała światu przyznanie tylko jednego infocoina.

Tym, co chcemy osiągnąć jest sposób by jednoznacznie odróżniać infocoiny od siebie. Potrzebują etykiety lub numeru seryjnego. Ala pisałaby wtedy wiadomość „Ja, Ala, przyznaję Bobowi jeden infocoin z numerem seryjnym 8770431”, i Bob (jak i ktokolwiek inny) mógłby wiedzieć, że został wysłany inny infocoin.

By ten sposób zadziałał potrzebujemy zaufane źródło numerów seryjnych dla infocoinów. Jednym ze sposobów by stworzyć takie źródło jest wprowadzenie banku. Ten bank miałby zapewniać numery seryjne dla infocoinów, śledzić kto posiada które infocoiny, i weryfikować czy strony w czasie transakcji nie oszukują.

Bardziej szczegółowo, przyjmijmy że Ala idzie do banku i mówi „Chcę pobrać jeden infocoin z mojego konta”. Bank redukuje saldo jej konta o jeden infocoin, i przypisuje jej nowy, nigdy nieużywany numer seryjny, powiedzmy 1234567. Wtedy, gdy Ala chce przesłać jej infocoin do Boba, ona podpisuje wiadomość „Ja, Ala, przyznaję Bobowi jeden infocoin, z numerem seryjnym 1234567”. Ale Bob nie akceptuje tak po prostu infocoina. Zamiast tego, kontaktuje się z bankiem, weryfikuje:

• a) Czy infocoin z danym numerem należy do Ali
• b) Ala nie wydała już wcześniej tego infocoina

Jeżeli oba warunki są spełnione, wtedy Bob mówi bankowi, że chce zaakceptować transfer infocoina, a bank aktualizuje swoje zapisy odnośnie infocoina. Infocoin należy od tej chwili do Boba i już dłużej nie należy do Ali.

Sprawienie, by wszyscy stali się kolektywnym bankiem.

Zaprezentowana ostatnio wersja protokołu brzmi obiecująco. Jednakże, my chcemy stworzyć coś bardziej ambitnego. Możemy wyeliminować bank całkowicie z protokołu. To wyraźnie zmienia naturę kryptowaluty. Oznacza to, że nie ma pojedynczej organizacji kontrolującej walutę. I wtedy, gdy pomyślisz o niewyobrażalnej władzy jaką dzierżyłby bank centralny – kontrola nad podażą pieniądza – to ogromna zmiana.

Pomysł polega na sprawieniu, by wszyscy w sieci P2P (kolektywnie) stali się bankiem. W szczególności, przyjmiemy że każdy używający Infocoina trzyma kompletny zbiór informacji o tym do kogo należą które infocoiny. Możesz myśleć o tym jako o ogólnodostępnym rejestrze przechowującym wszystkie informacje o wszystkich transakcjach w sieci Infocoin. Będziemy nazywali ten rejestr „block chain” (z ang. Łańcuch bloków [transakcji]), gdyż to w tak nazwanym elemencie Bitcoina znajduje się kompletny rejestr transakcji w sieci Bitcoin.

Teraz załóżmy, że Ala chce przesłać infocoin do Boba. Podpisuje wiadomość „Ja, Ala, przesyłam Bobowi jeden infocoin, z numerem seryjnym 1234567”, i dostarcza podpisaną wiadomość do Boba. Bob może użyć jego kopii łańcucha bloków by sprawdzić, czy rzeczywiście infocoin o podanym numerze seryjnym należy do Ali. Jeżeli należy, wtedy wysyła zarówno wiadomość Ali jak i jego wiadomość o akceptacji transakcji do całej sieci, i wszyscy w sieci Infocoin aktualizują ich kopie łańcucha bloków.

Obecnie mamy problem jak nadawane są numery seryjne, ale to jest wyjątkowo prosty problem do rozwiązania, z tego powodu odłożę jego rozwiązanie na później, w części poświęconej już Bitcoinowi. Trudniejszym problemem jest to, że protokół pozwala Ali oszukiwać przez wielokrotne wydawanie tych samych infocoinów (z ang. Double spending). Ala wysyła podpisaną wiadomość „Ja, Ala, przyznaję Bobowi jeden infocoin, z numerem seryjnym 1234567” do Boba, a jednocześnie podpisaną wiadomość „Ja, Ala, przyznaję Karolowi jeden infocoin, z [tym samym] numerem seryjnym 1234567” do Karola. Zarówno Bob jak i Karol używają ich kopii łańcucha bloków do zweryfikowania czy infocoin należy do Ali. Po warunkiem, że dojdzie do weryfikacji w prawie tej samej chwili (zanim będą mogli się nawzajem skomunikować), obaj zauważą, że tak, według ich kopii rejestru block chain infocoin należy do Ali. Z tego powodu obaj zaakceptują transakcję, jak również wyślą do sieci Infocoin ich wiadomość o akceptacji. I tutaj jest problem. W jaki sposób inni ludzie powinni aktualizować swoją kopię łańcucha bloków? Może nie być łatwego sposobu by zapewnić taki spójny, ogólnodostępny rejestr transakcji. I nawet gdy wszyscy mogą zgodzić się na spójny sposób aktualizacji ich kopii łańcucha bloków, ciągle istnieje problem czy to Bob czy Karol będzie oszukiwany.

Na pierwszy rzut oka zadanie Ali, która chce wielokrotnie wydać ten sam infocoin, wygląda na trudne. Jeżeli Ala wyśle wiadomość do Boba, Bob następnie może zweryfikować wiadomość, i powiedzieć wszystkim w sieci Infocoin (włączając w to Karola) by zaktualizowali swój łańcuch bloków. Gdy tak się stanie, Karol nie mógłby być oszukany przez Alę. Więc istnieje bardzo krótka chwila, przez którą Ala może wielokrotnie wydać ten sam infocoin. Tak czy inaczej jest to niepożądane by istniał w ogóle taki czas. Co gorsza, istnieją techniki które pozwoliłyby Ali wydłużyć ten czas. Mogłaby, na przykład, użyć analizy przepływu danych w sieci, by znaleźć moment w czasie, w którym Bob i Karol będą mieli duże opóźnienie w komunikacji. Albo mogłaby zrobić coś, by przerwać ich komunikację. Nawet jeśli może spowolnić komunikację między Karolem a Bobem chociażby o trochę, to pozwala na wielokrotne wydawanie w sposób dużo prostszy.

Jakie rozwiązanie możemy zaproponować, by uniemożliwić wielokrotne wydawanie? Oczywistym rozwiązaniem jest takie, w którym Ala wysyła Bobowi infocoina, a Bob nie próbuje zweryfikować transakcji samodzielnie. Zamiast tego, powinien wysłać wiadomość o możliwości transakcji z Alą do całej sieci użytkowników Infocoina, i poprosić ich o pomoc w rozstrzygnięciu czy transakcja jest prawowite. Jeśli kolektywnie zdecydują, że transakcja jest w porządku, wtedy Bob może zaakceptować infocoin, i wszyscy zaktualizują ich block chain. Taki typ protokołu może pomóc uniemożliwić wielokrotne wydawanie. Odtąd jeżeli Ala próbuje wydawać te same infocoiny zarówno do Boba i Karola, inne osoby w sieci zauważą to, powiedzą zarówno Bobowi i Karolowi, że jest problem z transakcją, i transakcja nie powinna dojść do skutku.

Bardziej szczegółowo, przyjmijmy że Ala chce przyznać Bobowi infocoin. Jak wcześniej, podpisuje wiadomość „Ja, Ala, przyznaję Bobowi jeden infocoin, z numerem seryjnym 1234567”, i dostarcza podpisaną wiadomość Bobowi. Jak wcześniej, Bob sprawdza poprawność transakcji, używając jego kopii łańcucha bloków, by upewnić się czy infocoin należy do Ali. Ale w tym momencie protokół jest zmodyfikowany. Bob nie akceptuje tak po prostu transakcji. Zamiast tego, wysyła wiadomość Ali do całej sieci. Inni uczestnicy sieci sprawdzają, czy Ala posiada ten infocoin. Jeśli tak, sieć wysyła informację „Tak, Ala posiada infocoin 1234567, może być zatem wysłany Bobowi”. Gdy wystarczająca ilość osób prześle wiadomość, każdy zaktualizuje swój block chain by pokazać że infocoin 1234567 teraz należy do Boba, a transakcja została zakończona sukcesem.

Ten protokół ma wiele nieprecyzyjnych elementów w obecnej fazie. Dla przykładu, co znaczy „wystarczająca liczba osób prześle wiadomość”? Co konkretnie oznacza „wystarczająca” w tym miejscu? Nie może to oznaczać każdego w sieci, gdyż nie możemy a priori zakładać, że wiemy jacy ludzie są w sieci Infocoin. Z tego samego powodu nie może oznaczać ustaloną, stałą część użytkowników sieci. Nie będziemy próbować skonkretyzować tych pomysłów w tej chwili. Zamiast tego, w następnym rozdziale określę poważny problem z tym podejściem, które powyżej zostało opisane. Naprawianie tego problemu będzie miało jednocześnie przyjemny skutek uboczny – uściśli powyższe pojęcia.

Dowód pracy

Załóżmy, że Ala chce wielokrotnie wydać swoje infocoiny w opisanym protokole, w którym weryfikacja opiera się o sieć. Mogłaby zrobić to przez przejęcie dużej części sieci Infocoin. Przyjmijmy, że używa zautomatyzowanego systemu by uruchomić dużą liczbę oddzielnych peerów w sieci, a reszta sieci nie wie, że są powiązane. Niech ich liczba wynosi miliard. Tak jak wcześniej, próbuje wielokrotnie wydać ten sam infocoin zarówno do Boba jak i Karola. Ale gdy Bob i Karol proszą sieć o walidację tranakcji, marionetki Ali zalewają sieć, ogłaszając do Boba, że pozytywnie zweryfikowali transakcję, i również do Karola. W ten sposób prawdopodobnie Bob i/lub Karol zostali oszukani. Istnieje sprytny sposób zapobiegania tego typu problemowi, używając pomysłu znanego pod pojęciem dowód pracy (z ang. Proof-of-work). Pomysł jest dla wielu nie intuicyjny i wymaga kombinacji dwóch pomysłów:

• 1) By zweryfikowanie transakcji w sieci stało się obliczeniowo kosztowne (umyślne podwyższenie złożoności obliczeniowej)
• 2) Wynagradzać użytkowników walidujących transakcję za ich pracę

Wynagrodzenie jest używane, by uczestnicy sieci próbowali walidować transakcje, nawet jeśli jest to obliczeniowo kosztowny proces. Zaletą zwiększenia kosztowności walidacji jest to, że walidacja nie może już być oszukana przez włączenie do sieci dużej ilości kontrolowanych przez atakującego członków sieci, ale przez całkowitą moc obliczeniową, którą mają do dyspozycji. Jak zobaczymy, w połączeniu ze sprytnym projektem będziemy mogli sprawić, że oszukiwanie wymagałoby by moc ta musiałaby być niewyobrażalnie wielka, co powoduje że byłoby niemożliwe lub przynajmniej nieekonomiczne by ją uzbierać.

To istota dowodu pracy. Ale by w pełni zrozumieć dowód pracy, musimy przejść poprzez szczegóły.

Przyjmijmy, że Ala wysyła do sieci wiadomość „Ja, Ala, wysyłam Bobowi jeden infocoin z numerem seryjnym 1234567”. Gdy inni członkowi sieci odbierają wiadomość, każdy dodaje ją do swojej kolejki, w której trzymane są wykonywane transakcje, o których zostali poinformowani, ale które nie zostały jeszcze zaakceptowane przez sieć. Na przykład inny użytkownik sieci, Dawid, może mieć następującą kolejkę realizowanych transakcji:

Ja, Tom, przyznaję Sue jeden infocoin, z numerem seryjnym 1201174.

Ja, Sydney, przyznaję Cynthii jeden infocoin, z numerem seryjnym 1295618.

Ja, Ala, przyznaję Bobowi jeden infocoin, z numerem seryjnym 1234567.

Dawid sprawdza jego kopię łańcucha bloków, i może sprawdzić czy każda transakcja jest poprawna. Chciałby pomóc przez rozesłanie wiadomości o poprawności transakcji do całej sieci.

Jednakże, zanim to zrobi, jako część protokołu walidacji Dawid musi rozwiązać ciężkie komputerowe puzzle – dowód pracy. Bez rozwiązania tych puzzli, reszta sieci nie zaakceptuje jego pozytywnej weryfikacji tranakcji.

Jakie puzzle musi Dawid rozwiązać? By to wyjaśnić, niech h będzie pewną funkcją skrótu (inaczej hashującą, miksującą) znana całej sieci – jest wbudowana w protokół. Bitcoin używa znanej funkcji SHA-256, ale jakakolwiek kryptograficznie bezpieczna funkcja skrótu będzie dobrze spełniać swoją rolę. Nadajmy kolejce transakcji Dawida etykietę l, by mieć nazwę do której będziemy móc się odnosić. Przypuśćmy, że Dawid dodał numer x (określany w języku angielskim jako nonce) do l i hashuje kombinację. Dla przykładu, jeżeli użyjemy l = „Hello, world!” (z ang. Witaj świecie. Oczywiście nie jest to lista transakcji, tylko ciąg użyty do celów zobrazowania działania) i noncję x = 0 wtedy (liczba wyjściowa jest w systemie szesnastkowym)

h("Hello, world!0") = 1312af178c253f84028d480a6adc1e25e81caa44c749ec81976192e2ec934c64

Puzzle, które Dawid musi rozwiązać – dowód pracy – polegają na znalezieniu takiej nonce x, by po dodaniu x do l i shashowaniu kombinacji wyjście zaczynało się od odpowiedniej liczby zer. Puzzle mogą być bardziej lub mniej trudne poprzez wymaganie mniejszej lub większej liczby zer na początku. Relatywnie prosty dowód pracy może wymagać trzech lub czterech zer na początku liczby, a bardziej złożony dowód pracy może wymagać zdecydowanie dłuższej sekwencji zer, powiedzmy 15 kolejnych zer. W obu przypadkach, powyższa próba do znalezienia nonce, gdy x =0, jest porażką, ponieważ wyjście z funkcji nie zaczyna się zerem. Próba z x = 1 również nie przynosi rezultatów.

h("Hello, world!1") = e9afc424b79e4f6ab42d99c81156d3a17228d6e1eef4139be78e948a9332a7d8

Możemy próbować po kolei kolejnych wartości dla nonce, x = 2,3,… W końcu, dla x = 4250 otrzymujemy:

h("Hello, world!4250") = 0000c3af42fc31103f1fdc0151fa747ff87349a4714df7cc52ea464e12dcd4e9

Ta nonce daje nam ciąg zaczynający się czterema zerami na początku wyjście z funkcji hashującej. To wystarczy, by rozwiązać prosty dowód pracy, ale nie jest wystarczające by rozwiązać bardziej trudny dowód pracy.

To, co powoduje trudność z rozwiązywaniem zagadki, jest fakt iż wyjście z kryptograficznej funkcji hashującej zachowuje się jak liczba losowa: zmiana na wejściu chociażby jednego bita powoduje całkowitą zmianę wartości wyjściowej, w sposób który ciężko przewidzieć. Więc jeśli chcemy mieć na wyjściu funkcji hashującej wartość zaczynającą się od 10 zer, Dawid będzie potrzebował średnio wypróbować różnych kombinacji dla x zanim znajdzie odpowiednią liczbę nonce. To bardzo wymagające zadanie, do rozwiązania którego potrzebna jest ogromna ilość mocy obliczeniowej.

Oczywiście, jest możliwe sprawienie by zagadka była bardziej lub mniej trudna do rozwiązania przez wymagania większej lub mniejszej ilości zer na wyjściu funkcji hashującej. W rzeczy samej, Bitcoin posiada dobrą kontrolę nad trudnością zagadki, przez używanie małej modyfikacji powyżej opisanej metody dowodu pracy. Zamiast wymagać odpowiedniej ilości zer, zagadka pracy w sieci Bitcoin opiera się na tym, by hash nagłówka bloku był mniejszy albo równy numerowi znanemu jako cel. Ten cel jest automatycznie dostosowywany by średnio walidacja bloków Bitcoina wymagała 10 minut.

(W praktyce istnieje tutaj spora losowość w tym jak długo sieć będzie walidować blok – czasem nowy blok jest walidowany w minutę lub dwie czasem może zabrać to nawet 20 minut lub dłużej. To dosyć prosta sprawa, by zmodyfikować protokół Bitcoin by czas walidacji miał mniejszy rozrzut wokół 10 minut. Zamiast rozwiązywać pojedynczą zagadkę, możemy wymagać by wiele zagadek zostało rozwiązanych; z odpowiednio ostrożnym projektowaniem jest możliwe zdecydowane zmniejszenie wariacji czasu podczas walidacji bloku transakcji.)

W porządku, przypuśćmy że Dawid ma szczęście i znalazł odpowiednią nonce, x. Świętujemy! (Będzie nagrodzony za znalezienie odpowiedniej liczby nonce, jak opisano poniżej). Wysyła blok transakcji, które zatwierdza do sieci, razem z odpowiednią, znalezioną wartością x. Inni uczestnicy w sieci Infocoin mogą zweryfikować, że x jest poprawnym rozwiązaniem zagadki będącej dowodem pracy. I wtedy oni aktualizują ich łańcuch bloków, by zawierał nowy blok transakcji.

By pomysł, że dowód pracy mógł w ogóle być zrealizowany, użytkownicy sieci muszą mieć zachętę do weryfikowania transakcji. Bez tej nagrody nie maja powodu by rozszerzać wartościową moc obliczeniową, by pomagać walidować transakcje innych osób. A jeśli użytkownicy sieci nie chcą rozszerzyć ich mocy obliczeniowej, wtedy cały system nie będzie działał. Rozwiązaniem tego problemu jest nagradzanie ludzi, którzy walidują realizowane transakcje. W szczególności, przyjmijmy że nagroda dla każdego kto skutecznie zweryfikuje transakcje, będzie opłacana za pomocą pewnej ilości infocoinów. Nagroda w infocoinach jest wystarczająco wysoka, jeśli daje zachętę do uczestnictwa w walidacji.

W protokole Bitcoin, ten proces walidacji nazywany jest kopaniem (z ang. Mining). Dla każdego bloku zweryfikowanych transakcji, osoba której udało się je zweryfikować, otrzymuje nagrodę w bitcoinach. Wstępnie, została ona ustalona na 50 bitcoinów. Po każdych 210,000 zweryfikowanych bloków (w przybliżeniu raz na cztery lata) nagroda jest dwa razy mniejsza (licząc w bitcoinach). Na tą chwilę zdarzyło się to tylko raz, i obecna nagroda wynosi 25 bitcoinów. To zmniejszanie o połowę będzie kontynuowane co około cztery lata aż do roku 2140. We wspomnianym roku nagroda spadnie poniżej 10-8 bitcoina za blok. Akutalnie 10-8 jest najmniejszą porcją Bitcoina, i jest nazywana satoshi. Więc w 2140 podaż przestanie rosnąć. Jednakże, to nie spowoduje eliminacji zachęty do walidacji transakcji. Bitcoin pozwala również ustanowić pewną kwotę podczas wysyłania transakcji jako opłata/prowizja transakcyjna, która idzie do górnika który pomaga zweryfikować transakcję. Na początku, gdy sieć Bitcoin dopiero powstawała, prowizje transakcyjne były zwykle ustawione na zero, ale gdy Bitcoin zdobył popularność, opłaty transakcyjne stopniowo rosły, aby teraz były pokaźnym dodatkiem do zachęty na poziomie 25 bitcoinów za blok.

Możesz myśleć o dowodzie pracy jako konkurencji wobec akceptowania transakcji. Każdy wpis o transakcji kosztuje odrobinę mocy obliczeniowej. Szansa na wygranie przez danego górnika konkurencji jest (w przybliżeniu, z pewnymi zastrzeżeniami) proporcjonalne do całkowitej mocy obliczeniowej którą posiada. Więc, na przykład, jeżeli górnik kontroluje jeden procent mocy obliczeniowej używanej do weryfikacji transakcji, wtedy mają w przybliżeniu jeden procent szansy na wygranie konkurencji (w hashowaniu tego konkretnego bloku, później będzie kolejna szansa i kolejna). Więc jeśli w konkurencji bierze udział dużo osób z dużą ilością mocy obliczeniowej, nieuczciwy górnik będzie miał małą szansę, by zakłócić proces weryfikacji, chyba że rozszerzy on ogromnie swoją moc obliczeniową.

Oczywiście, to że nieuczciwy górnik ma małą szansę na uszkodzenie łańcucha bloków, nie jest wystarczające by dać nam bezpieczną walutę. W szczególności, dalej nie omówiliśmy jak ostatecznie uporać się z problemem wielokrotnego wydawania.

Przeanalizuję wielokrotne wydawanie krótko. Zanim to zrobię, chcę powiedzieć jeszcze o jednym, dotychczas nie omówionym, istotnym szczególe Infocoina. Chcielibyśmy, by sieć Infocoin dokładnie zgadzała się co do kolejności w której przebiegają transakcje. Jeśli nie mamy tego typu porządkowania, wtedy w danym momencie może nie być możliwe rozstrzygnięcie do kogo należy dany infocoin. By móc rozwiązać ten problem będziemy potrzebowali by nowe bloki zawsze zawierały wskaźnik, do ostatniego zweryfikowanego już bloku w łańcuchu, dodany obok danych o zatwierdzonych transakcjach. (Wskaźnik jest obecnie po prostu hashem wcześniejszego bloku). Więc zwykle łańcuch bloków jest tylko liniowym łańcuchem bloków transakcji, ułożonych jeden po drugim, z ostatnimi blokami zawierającymi wskaźnik do bloku wykonanego bezpośrednio przed nim:

Most recent block – ostatnio wygenerowany blok (najnowszy)

Od czasu do czasu, w łańcuchu bloków znajdzie się rozwidlenie. Może się ono zdarzyć, na przykład, jeśli dwóch górników zweryfikuje blok transakcji niemal jednocześnie – zarówno rozgłoszą sieci ich nowo zweryfikowane bloki, i niektórzy ludzie zaktualizują ich łańcuch bloków dodając blok od pierwszego, a pozostali od drugiego górnika:

To powoduje dokładnie taki problem, którego chcemy uniknąć – nie jest dalej jasne w której kolejności transakcje zaszły, i może nie być jasne kto jest właścicielem których infocoinów. Szczęśliwi się składa, że istnieje prosty sposób usuwania rozwidleń. Zasada jest taka: jeśli zachodzi rozwidlenie, uczestnicy sieci Infocoin śledzą oba rozwiązania. Ale w pewnym momencie, poszczególni górnicy pracują by rozszerzyć tylko jeden z bloków, który jest dłuższy w łańcuchu bloków.

Przyjmijmy, dla przykładu, że mamy rozwidlenie w którym niektórzy górnicy otrzymają najpierw blok A, a niektórzy blok B. Ci górnicy, którzy otrzymają blok A będą kontynuować kopanie w oparciu o to rozwidlenie łańcucha, podczas gdy inni będą kopać w oparciu o rozwidlenie B. Załóżmy, że górnicy pracujący na rozwidleniu B jako pierwsi udanie zweryfikują następny blok realizowanych transakcji:

Po tym, jak rozgłoszą to w sieci, górnicy pracujący nad rozwidleniem A zauważą to, że rozwidlenie B jest dłuższe, i przestawią się na pracę nad tym rozwidleniem. Szybko praca nad rozgałęzieniem A przestanie być wykonywana, i wszyscy będą pracować nad tym samym łańcuchem bloków, a blok A będzie ignorowany. Oczywiście, każda niezrealizowana transakcja w A będzie ciągle w kolejkach górników pracujących nad rozgałęzieniem B, z tego powodu wszystkie transakcje zostaną zrealizowane.

To samo stałoby się, gdyby to blok A został zweryfikowany – przez górnika, który pracował nad wydłużeniem rozwidlenia z blokiem A.

Nie ważne jaki potoczy się los, ten proces pozwala zapewnić iż łańcuch bloków jest w tej samej postaci akceptowany przez całą sieć Infocoin, w określonej kolejności. W przypadku Bitcoina, transakcja nie jest uznawana za potwierdzoną dopóki:

• 1) Jest częścią bloku o najdłuższym rozwidleniu
• 2) Powstało przynajmniej 5 bloków, które są nowsze niż blok w którym znajduje się transakcja

W tym przypadku powiemy, że transakcja ma 6 potwierdzeń. To daje sieci czas do wspólnego uzgodnienia dotyczącego kolejności bloków. Użyjemy tej strategii dla Infocina.

Po tym, jak zrozumieliśmy porządkowanie kolejności transakcji w czasie, przyjrzymy się co stanie się, gdy nieuczciwy uczestnik sieci próbuje wielokrotnie wydać te same infocoiny. Przyjmijmy, Ala próbuje wielokrotnie wydać infocoiny do Boba i Karola. Jednym z możliwych podejść jest dla niej próba walidacji bloku zawierającego obie transakcje. Przyjmując, że ma jeden procent całkowitej mocy obliczeniowej sieci, może okazjonalnie mieć szczęście i zweryfikować blok poprzez wykonanie dowodu pracy. Nieszczęśliwie dla Ali, wielokrotne wydawanie będzie natychmiastowo dostrzeżone przez innych uczestników sieci i odrzucone, pomimo rozwiązania dowodu pracy. Więc nie musimy się tego obawiać.

Bardziej poważnym problemem jest, jeśli roześle dwie oddzielne transakcje, w których przyznaje ten sam infocoin odpowiednio Bobowi i Karolowi. Może, na przykład, rozesłać jedną transakcję do podgrupy górników, a drugą do drugiej grupy górników, mając nadzieję że w ten sposób obie transakcje zostaną zweryfikowane. Na szczęście, w tym przypadku, jak już zobaczyliśmy, sieć potwierdzi jedną z tych transakcji, ale nie obie. Więc, dla przykładu, transakcja Boba może być zweryfikowana, w tym przypadku Bob będzie mógł być pewny tego, że transakcja zaszła. W tym czasie, Karol zauważy iż jego transakcja nie został potwierdzona, więc odrzuci ofertę Ali. Więc to nie jest już dalej problemem. Ala wiedząc to, w zasadzie nie ma po co nawet próbować oszukiwać.

Ważnym przypadek wielokrotnego wydawania zachodzi, gdy Ala = Bob, na przykład Ala próbuje wydać infocoin do Karola, który jednocześnie próbuje dać sobie. To brzmi jakby było łatwe do wykrycia i obsłużenia przez sieć, ale oczywiście, łatwo jest w sieci, dla jednej organizacji/osoby ustanowić, wiele identyfikatorów, więc taka możliwość musi być brana pod uwagę. W tym przypadku, strategia Ali to czekanie zanim Karol zaakceptuje infocoin, co stanie się po 6 krotnym potwierdzeniu transakcji w najdłuższym łańcuchu. Wtedy spróbuje rozwidlić łańcuch przed blokiem z transakcją z Karolem, dodając blok który zawiera transakcję w której ona płaci sama sobie.

Nieszczęśliwie dla Ali, teraz będzie jej bardzo trudno dogonić najdłuższe rozwidlenie. Inni górnicy nie będą chcieli jej pomóc, odkąd oni będą pracować na najdłuższym rozwidleniem. I jeśli Ala nie jest w stanie rozwiązywać dowód pracy co najmniej tak samo szybko jak cała reszta sieci łącznie – w przybliżeniu oznacza to kontrolę ponad 50% mocy całej sieci – wtedy będzie coraz bardziej z tyłu w wyścigu rozwiązywania dowodu pracy. Oczywiście, może mieć szczęście. My możemy, na przykład, wyobrazić sobie scenariusz w którym Ala kontroluje jeden procent mocy obliczeniowej sieci, ale tak się przydarza, że Ala ma szczęście i bardzo szybko znajduje rozwiązanie dla 6 kolejnych zagadek – dowodów pracy, zanim reszta sieci znajdzie więcej bloków. W tym przypadku, będzie mogła przejąć kontrolę nad łańcuchem bloków. Tylko, że taki przypadek może się przydarzyć z prawdopodobieństwem . Bardziej ogólna analiza pokazuje, że prawdopodobieństwo iż Ali kiedykolwiek uda się dogonić resztę sieci jest pomijalnie małe, chyba że ma moc obliczeniową pozwalającą rozwiązywać zagadkę co najmniej tak szybko jak wszyscy inni górnicy razem wzięci.

Oczywiście, to nie jest rygorystyczna analiza bezpieczeństwa pokazująca, że Ala nie może wielokrotnie wydawać. To tylko argument dotyczący prawdopodobieństwo takiego zdarzenia. Oryginalne pismo dotyczące i wprowadzające Bitcoina, w prawdzie, nie zawiera rygorystycznej analizy bezpieczeństwa, a jedynie nieformalny argument, który tutaj przytoczyłem. Społeczność badaczy bezpieczeństwa ciągle analizuje protokół Bitcoin i próbuje znaleźć możliwe jego wady. Możesz zajrzeć do tych badań, i ja również wspomniałem o kilku powiązanych problemach w „Problemy dla autora” poniżej. Będąc uczciwym w tym miejscu myślę, że werdykt jak bezpieczny jest Bitcon jest ciągle niewydany.

Dowód pracy i pomysł na kopanie jest powodem do wielu pytań. Jak wielka powinna być nagroda do zachęcenia ludzi do kopania? Jak zmiana podaży infocoinów wpłynie na Infocoinową gospodarkę? Czy w przyszłości kopanie w sieci Infocoin skończy w rękach niewielkiej lub co gorsza pojedynczej organizacji? Jeśli będzie ich mało, czy nie zagraża to całej sieci? Możliwe, że opłaty transakcyjne zrównoważą problemy wynikłe z małej ilości nagrody za kopanie – nie spowoduje to niechcianego źródła problemów, i uczyni małych transakcji niemile widzianymi? To ważne pytania, ale cel tego artykułu jest inny niż odpowiadanie na nie. W przyszłych wpisach być może powrócę (w kontekście Bitcoina) do tych pytań. Na razie pozostańmy na drodze od zrozumienia jak protokół Bitcoin działa.

Problemy dla autora

1. Nie rozumiem dlaczego wielokrotne wydawania nie może być uniemożliwione w prostszy sposób używając two-phase commit (dwu fazowe wykonywanie). Przyjmijmy, że Ala chce wielokrotnie wydać infocoin do zarówno Boba i Karola. Pomysł jest taki, że Bob i Karol mogliby rozesłać do sieci wiadomości z pytaniem: „Czy powinienem zaakceptować transakcję?”. Wtedy czekaliby oni pewien odcinek czasu – prawdopodobnie liczony w minutach – by usłyszeć jakikolwiek oznak sprzeciwu, które dowiodłyby że Ala próbuje wielokrotnego wydawania. Jeżeli nic takiego by nie usłyszeli (i jeśli nie byłoby sygnałów o problemach z utrzymaniem transmisji w sieci), wtedy zaakceptowaliby transakcje. Ten protokół potrzebuje być zabezpieczony przed atakami sieciowymi, ale wygląda mi na rdzeń dobrej alternatywnej idei. Jak dobrze takie rozwiązanie by działało? Jakie skutki uboczne i zalety miałoby to w porównaniu do pełnego protokołu Bitcoin?
2. Wcześniej w sekcji wspomniałem, że istnieje prosta droga redukcji wariacji czasu potrzebnego do walidowania bloku transakcji. Jeżeli ta wariacja jest zbytnio zredukowana, wtedy tworzy się nowy sposób ataku. Przypuśćmy, że Ala próbuje rozwidlić łańcuch bloków w taki sposób, że: a) Jedno rozwidlenie zaczyna się blokiem, którym Ala wpłaca pieniądze samej sobie, natomiast drugie rozwidlenia zaczyna się blokiem w którym Ala płaci Bobowi; b) Oba bloki są rozgłoszone w [prawie] tym samym momencie, a górnicy podzielą się na dwie równe części próbujące rozwiązać nowy blok, jedna część z rozwidleniem A, druga B c) Ala próbuje użyć swojej mocy obliczeniowej do prób utrzymania rozwidlenia na blisko takim samym poziomie, kopiąc w tym bloku, który staje się krótszy – jest to w normalnych warunkach trudne zadanie, ale staje się wiele prostsze jeżeli odchylenie standardowe czasu walidacji jest zdecydowanie mniejsze niż opóźnienie sieci d) Po tym, jak po obu stronach rozwidlenia dokonana została nadbudowa przez 5 kolejnych bloków, Ala rzuca swą moc obliczeniową by zwiększyć prawdopodobieństwo, że to transakcja do Karola została potwierdzona e) Po tym, jak transakcja do Karola została potwierdzona, wtedy rzuca swoją moc do drugiego rozwidlenia i próbuje dogonić dłuższy łańcuch. Ta strategia balansowania będzie miała niewielką szansę sukcesu, lecz o wiele większą niż w przypadku normalnego protokołu Bitcoin, z dużą wariacją czasu potrzebnego do weryfikacji. Czy istnieje możliwość ominięcia tego problemu?
3. Przyjmijmy że oprogramowanie do kopania zawsze odkrywa nonce rozpoczynając od x=0, następnie x=1;x=2;…. Jeżeli tak robią wszyscy, albo nawet wyraźna część, kopiący w sieci Bitcoin, wtedy tworzy to podatność na atak. Dosłownie, istnieje możliwość dla kogoś do zwiększenia jego szans w rozwiązywaniu dowodu pracy tylko przez rozpoczęcie od innej, większej liczby nonce. Bardziej ogólnie, może być możliwe dla atakujących wykorzystanie symetrycznych wzorców w sposobie, w którym kopiący odkrywają przestrzeń liczb nonce. Bardziej ogólnie, w analizie tej sekcji niebezpośrednio założyłem pewien rodzaj symetrii pomiędzy kopiącymi. W praktyce będą asymetrie i przez to analiza bezpieczeństwa będzie musiała brać pod uwagę te asymetrie.

Bitcoin

Nie zajmujmy się już projektowaniem Infocoina, ale opisem aktualnej wersji protokołu Bitcoin. W protokole jest kilka nowych pomysłów, ale z jednym wyjątkiem (opisanym poniżej) są głównie oczywistymi modyfikacjami protokołu Infocoin.

By używać Bitcoina w praktyce, najpierw musisz zainstalować program-portfel na swoim komputerze. By dać Tobie obraz jak to wygląda, poniżej zamieszczam zrzut ekranu ukazujący program MultiBit. Możesz zobaczyć saldo konta po lewo – 0.06555555, około 70 dolarów przy kursie wymiany, w którym tworzyłem zrzut ekranu – a po prawej dwie ostatnie transakcje, którymi przesłano mi te bitcoiny.

Przyjmując, że jesteś handlowcem, który otworzył sklep w Internecie, i zdecydował się pozwolić ludziom płacić za pomocą sieci Bitcoin. To, co musisz zrobić to powiedzieć swojemu programowi-portfelowi by wygenerował adres Bitcoin. W odpowiedzi, wygeneruje to parę kluczy: prywatny i publiczny, a wtedy zahashuje Twój klucz publiczny i w ten sposób uformuje Twój adres w sieci Bitcoin:

Wtedy Ty wysyłasz Twój adres Bitcoin do osób, które chcą kupować od Ciebie. Możesz to zrobić w emailu, albo nawet opublikować go publicznie na stronie internetowej. Jest to bezpieczne, gdyż adres to tylko hash klucza publicznego, który bez utraty bezpieczeństwa można opublikować światu. (Powrócę później do tematu dlaczego adres Bitcoin jest hashem, a nie kluczem publicznym.)

Osoba, które chce Tobie zapłacić generuje transakcję. Spójrzmy na dane z aktualnej transakcji opiewającej na bitcoinów. To co przedstawiłem poniżej jest bardzo podobne do surowych danych. Jest zmienione na trzy sposoby:

• a) Dane zostały zdeserializowane
• b) Dodano numery linii by móc się do nich odnosić
• c) Skróciłem wiele hashy i kluczy publicznych, przez wstawienie pierwszych 6 cyfr w zapisie szesnastkowym, gdy w rzeczywistości są dłuższe.

Oto dane:

1.  {"hash":"7c4025...",
2.  "ver":1,
3.  "vin_sz":1,
4.  "vout_sz":1,
5.  "lock_time":0,
6.  "size":224,
7.  "in":[
8.    {"prev_out":
9.      {"hash":"2007ae...",
10.      "n":0},
11.    "scriptSig":"304502... 042b2d..."}],
12. "out":[
13.   {"value":"0.31900000",
14.    "scriptPubKey":"OP_DUP OP_HASH160 a7db6f OP_EQUALVERIFY OP_CHECKSIG"}]}

Przyjrzyjmy się danym linia po linii. Linia pierwsza zawiera hash reszty transakcji, 7c4025…, wyrażony w liczbach szesnastkowych. Jest używany jako identyfikator dla transakcji.

Linia 2 mówi nam, że ta transakcja w wersji 1 protokołu Bitcoin.

Linie 3 i 4 mówią nam, że transakcja ma odpowiednio: jedno wejście i jedno wyjście. Omówią później transakcje z większą ilością wejść i wyjść i dlaczego jest to użyteczne.

Linia 5 zawiera wartość dla lock_time, który może być do kontroli tego, kiedy transakcja ma być sfinalizowana. Dla większości dzisiaj wykonywanych transakcji w sieci Bitcoin lock_time jest ustawione na 0, co oznacza że transakcja jest finalizowana natychmiast.

Linia 6 mówi nam o rozmiarze (w bajtach) transakcji. Warto zanotować, że nie jest to związane z ilość przesyłanych jednostek pieniężnych. Na omówienie tego przyjdzie czas.

Linie od 7 do 11 definiują wejście transakcji. W szczególności, linie od 8 do 10 mówią nam, iż wejście ma być wzięte z wyjścia wcześniejszej transakcji, o podanym hashu, który jest wyrażony w numerze o notacji szesnastkowej jako 2007ae…. Zapis n=0, że to będzie dotyczyło pierwszego wyjścia tej transakcji; omówię później jak działają wielokrotne wejścia i wyjścia transakcji, więc nie zastanawiaj się nad tym teraz. Linia 11 zawiera sygnaturę osoby wysyłającej walutę, 304502…, po której występuje spacja, a następnie odpowiedni klucz publiczny, 04b2d…. Znów, liczby są w formacie szesnastkowym.

Jedna z rzeczy wartych zanotowania o wejściu nie ma tutaj niczego dokładnie określającego jaka ilość bitcoinów z poprzedniej transakcji powinna zostać wydana w tej transakcji. Wszystkie bitcoiny z n=0-wego wyjścia z poprzedniej transakcji zostały wydane. Więc, dla przykładu, jeżeli n=0-we wyjście wcześniejszej transakcji było równe dwóm bitcoinom, wtedy 2 bitcoiny będą wydane w tej transakcji. Wygląda to na niewygodne ograniczenie – jak próba kupowania chleba za pomocą 20 dolarowego banknotu, i brak możliwości rozmienienia banknotu. Rozwiązaniem jest, oczywiście, posiadanie mechanizmu dla zapewnienia wymiany. To może być wykonane używając transakcji z wieloma wejściami i wyjściami, które będziemy omawiali w następnej sekcji.

Linie od 12 do 14 opisują nasze wyjście z transakcji. W szczególności, linia 13 mówi nam o wartości na wyjściu, 0.319 bitcoinów. Linia 14 jest trochę skomplikowana. Główną rzeczą wartą podkreślenia jest ciąg a7db6f… który jest adresem Bitcoin odbiorcy środków (zapisany w postaci heksadecymalnej). Linia 14 jest aktualnie wyrażeniem w Bitcoinowym języku skryptowym. Nie zamierzam opisać tego języka w tym wpisie, ważną rzeczą jest to że a7db6f… jest adresem Bitcoin.

Możesz teraz zauważyć, przy okazji, jak Bitcoin odpowiada na problem z wcześniejszej sekcji: Skąd pochodzą numery seryjne bitcoinów? Rolę numerów seryjnych spełniają hashe transakcji. W transakcji powyżej, dla przykładu, odbiorca otrzymuje 0.319 bitcoinów, które wychodzą z pierwszego wyjścia wcześniejszej transakcji z hashem 2007ae… (linia 9). Jeśli wrócisz i spojrzysz w łańcuch bloków szukając tej transakcji, zobaczyłbyś że wyjście przychodzi z wcześniejszej transakcji. I tak dalej.

Z używania hashy transakcji zamiast numerów seryjnych wynikają dwie właściwości. Po pierwsze w Bitcoinie nie potrzeba trwałych „monet”, jest tylko długi łańcuch transakcji. Po drugie, przez tego rodzaju rozwiązanie nie potrzebny jest żaden zcentralizowany autorytet wydający numery seryjne. Zamiast tego, numery seryjne mogą być samo-generowalne, po prostu przez hashowanie transakcji.

Fakt jest taki, że możliwe jest podążaniem po łańcuchu bloków transakcji wstecz i prześledzenie historii. Ostatecznie, proces ten musi zostać przerwany. To może się stać w jeden z dwóch sposobów. Pierwszy to znalezienie pierwszej dokonanej transakcji, zawartej w tak zwanym Genesis block (Blok genezy, stworzenia? Pierwszy stworzony blok, po angielsku pierwsza księga Biblii zwie się The Book of Genesis). To specjalna transakcja, nie posiadająca wejść, ale 50 bitcoinów na wyjściu. W innych słowach, ta transakcja ustanawia początkową podaż bitcoinów. Pierwszy Blok jest traktowany różnie przez różne klienty sieci Bitcoin, i nie będę się wdawał w szczegóły, pomimo że jest podobny do powyżej omówionej transakcji. Możesz zobaczyć zdeserializowane dane tutaj, a poczytać o tym bloku tutaj.

Drugą możliwością jest podążanie wstecz po łańcuchu, aż dotrzesz do tak zwanej transakcji coinbase transaction. Z wyjątkiem pierwszego bloku, każdy blok transakcji w łańcuchu bloków zaczyna się od specjalnej transakcji coinbase. To transakcja, w której górnik za poprawne zwalidowanie bloku dostaje nagrodę. Transakcja ta używa podobnego, ale nie identycznego formatu w porównaniu do omówionego przykładu. Nie będę opisywał szczegółów formatu, ale jeśli chcesz zobaczyć przykład, spójrz tutaj. Możesz również poczytać o transakcjach coinbase tutaj.

Coś o czym nie mówiłem wcześniej precyzyjnie – co dokładnie jest cyfrowo podpisywane przez sygnaturę w linii 11. Oczywistym jest, że ten który płaci musi podpisać całą transakcję (niezależnie od hashu transakcji, który oczywiście musi być wygenerowany później). Obecnie, to nie jest przeprowadzane – niektóre części transakcji są omijane. To powoduje, że niektóre części transakcji są podatne na atak np. mogą być zmienione po podpisaniu. Jednakże, ta podatność na atak nie zawiera części takich jak ilość bitcoinów na którą opiewa transakcja, adres odbiorcy i nadawcy. Wspomniane części są podpisywane i nie mogą być zmienione później. Muszę przyznać nie wczytywałem się w szczegóły tej kwestii protokołu Bitcoin. Zebrałem informacje, że podatność ta jest dyskutowana przez deweloperów społeczności Bitcoina, i podjęto wysiłki by zniwelować lub wyeliminować te podatności.

Transakcje z wieloma wejściami i wyjściami

W ostatniej sekcji opisałem jak działają transakcje z pojedynczymi wejściami i wyjściami. W praktyce, często jest bardzo potrzebne stworzenie transakcji Bitcoin z wieloma wejściami lub wyjściami. O tym dlaczego powiem później. Najpierw spójrzmy na dane z aktualnej transakcji:

1. {"hash":"993830...",
2. "ver":1,
3. "vin_sz":3,
4.  "vout_sz":2,
5.  "lock_time":0,
6.  "size":552,
7.  "in":[
8.    {"prev_out":{
9.      "hash":"3beabc...",
10.        "n":0},
11.     "scriptSig":"304402... 04c7d2..."},
12.    {"prev_out":{
13.        "hash":"fdae9b...",
14.        "n":0},
15.      "scriptSig":"304502... 026e15..."},
16.    {"prev_out":{
17.        "hash":"20c86b...",
18.        "n":1},
19.      "scriptSig":"304402... 038a52..."}],
20.  "out":[
21.    {"value":"0.01068000",
22.      "scriptPubKey":"OP_DUP OP_HASH160 e8c306... OP_EQUALVERIFY OP_CHECKSIG"},
23.    {"value":"4.00000000",
24.      "scriptPubKey":"OP_DUP OP_HASH160 d644e3... OP_EQUALVERIFY OP_CHECKSIG"}]}

Omówmy linia po linii. Format jest bardzo podobny do transakcji pojedynczego wejścia i wyjścia, więc omówię ten format szybko.

Linia 1 zawiera hash reszty transakcji. Jest używany jako identyfikator transakcji.

Linia 2 mówi o tym, że transakcja jest w wersji 1 protokołu Bitcoin.

Linie 3 i 4 mówi o tym, że transakcja ma odpowiednio trzy wejścia i dwa wyjścia.

Linia 5 zawiera lock_time. Jak we wcześniejszym przykładzie jest ustawiona na 0, co oznacza że transakcja będzie sfinalizowana natychmiast.

Linia 6 mówi o wielkości transakcji w bajtach.

Linie od 7 do 19 definiują listę wejść transakcji. Każde odpowiada do wyjścia poprzedniej transakcji Bitcoin.

Pierwsze wejście jest opisane w liniach od 8 do 11.

W szczególności, od linie od 8 do 10 mówią nam, że wejście jest wzięte z n=0-wego wyjścia poprzedniej transakcji identyfikowanej hashem 3beabc…. Linia 11 zawiera sygnaturę, po niej występuje spacja, a następnie klucz publiczny osoby wysyłającej bitcoiny.

Linie od 12 do 15 definiują drugie wejście, o podobnym formacie do tego z liń 8..11. Linie od 16 do 19 definiują trzecie wejście.

Linie od 20 do 24 definiują listę zawierającą dwa wyjścia z każdej transakcji.

Pierwsze wyjście jest zdefiniowane w liniach 21 i 22. Linia 21 mówi, że wartość na wyjściu wynosi 0.01068000 bitcoina. Jak wcześniej, linia 22 jest wyrażeniem w języku skryptowym Bitcoina. Najważniejszym elementem do zauważenia jest ciąg e8c30622…, które jest adresem Bitcoin odbiorcy środków.

Drugie wyjście jest zdefiniowane w liniach 23 i 24, z podobnym formatem do pierwszego wyjścia.

Jedyną widoczną dziwnością w tym opisie jest to, że każde wyjście ma przypisaną wartość Bitcoin, natomiast wejścia nie. Oczywiście, te wartości odpowiednich wejść mogą być znalezione sprawdzając odpowiednie wyjście wcześniejszych transakcjach. W standardowej transakcji Bitcoin, suma wszystkich wejść musi być co najmniej tak duża jak suma wszystkich wyjść. (Jedynym wyjątkiem jest Pierwszy Blok i transakcje coinbase, które dodają do ogólnej puli pewną ilość bitcoinów.) Jeżeli wejście po zsumowaniu jest większe niż suma wszystkich na wyjściu, wtedy różnica jest używana jako prowizja transakcyjna. Jest ona płacona do tego górnika, któremu uda się zwalidować blok zawierający tą transakcję.

To wszystko jeżeli chodzi o transakcje z wieloma wejściami i wyjściami. Są bardzo prostą modyfikacją transakcji pojedynczego wejścia-wyjścia.

Jednym z fajnych zastosowań transakcji z wieloma wejściami i wyjściem jest pomysł na rozmienianie. Przyjmijmy, że chcę wysłać Tobie 0.15 bitcoina. Mogę to zrobić wydając 0.2 bitcoina, którego otrzymałem w poprzedniej transakcji. Oczywiście, nie chcę wysłać Ci całe 0.2 bitcoina. Rozwiązaniem jest wysłanie tobie 0.15 bitcoin, i wysłanie 0.05 bitcoina do mojego adresu. Te 0.05 będą służyły do rozmienia transakcji Bitcoin. Oczywiście, różni się to od rozmieniania pieniędzy w sklepie, w tym przypadku przecież płacisz sam sobie, ale ogólny, szerszy pomysł jest podobny.

Wnioski

To zakończenie podstawowego opisu głównych idei stojących u fundamentów protokołu Bitcoin. Oczywiście, ominąłem wiele szczegółów – to nie jest oficjalna specyfikacja. Jednakże opisałem główne idee używane w najbardziej typowych zastosowaniach.

Jako, że zasady Bitcoina są proste i łatwe do zrozumienia, to nie oznacza że łatwo jest zrozumieć konsekwencje tych zasad. O Bitcoinie można powiedzieć wiele więcej, i prześledzę wiele z tych zagadnień w następnych wpisach. Obecnie, odniosę się do kilku niewspomnianych spraw.

Jak anonimowy jest Bitcoin? Wiele osób twierdzi, że Bitcoin może być używany anonimowo. Te twierdzenia zaprowadziły do zorganizowania takich miejsc jak Silk Road (i wielu sukcesorów), które specjalizują się w handlu nielegalnymi dobrami. Jednakże, twierdzenie że Bitcoin jest anonimowy to mit. Łańcuch bloków jest ogólnodostępny, co oznacza że jest możliwe dla każdego sprawdzenie każdej kiedykolwiek dokonanej transakcji w sieci Bitcoin.

Pomimo tego, że adresy Bitcoin nie są natychmiastowo powiązywalne z identyfikatorami z prawdziwego świata (imię, nazwisko itd.), naukowcy zajmujący się techniką cyfrową wykonali kawał roboty odkrywając jak de-anonimizować „anonimowe” sieci społecznościowe. Łańcuch bloków jest bajkowym celem dla tych technik. Byłbym bardzo zdziwiony, gdyby zdecydowana większość użytkowników Bitcoina nie była identyfikowalna z dużym stopniem pewności w prosty sposób w bliskiej przyszłości. Stopień pewności nie byłby wystarczająco wysoki, by postawić kogoś w stan oskarżenia, ale wystarczająco duży by zidentyfikować prawdopodobne cele. Ponadto, identyfikacja byłaby możliwa przez cały czas trwania sieci Bitcoin, co oznacza że osoba która kupiła narkotyki z Silk Road w 2011 roku byłaby ciągle identyfikowalna w, powiedzmy, 2020 roku. Te techniki deanonimizacji są szeroko znane badaczom bezpieczeństwa IT jak i również dla NSA. Nie byłbym zdziwiony, gdyby NSA i inne agencje już teraz nie zdeanonimizowały wielu użytkowników. To ironia losu, że Bicoin jest często jest reklamowany jako anonimowy. Nie jest. Bitcoin jest za to prawdopodobnie najbardziej otwartym i transparentnym instrumentem finansowym, jaki widział świat.

Czy możesz stać się bogaty za sprawą Bitcoina? Być może. Tim O’Reilly pewnego razu powiedział: „Pieniądze są jak paliwo w samochodzie – musisz na nie uważać albo skończysz na poboczu drogi – ale dobrze żyte życie nie jest podróżą po stacjach benzynowych!” Wiele osób zainteresowało się Bitcoinem, których życiową misją wydaje się być podróż do rzeczywiście dużej stacji paliw. Muszę przyznać, że bardzo mnie to dziwi. To, co według mnie, jest bardziej interesujące jest myślenie o Bitcoinie i innych kryptowalutach jako drodze do tworzenia nowych form kolektywnego zachowania. To intelektualnie fascynujące, oferuj wiele cudownych, nowych możliwości, jest społecznie wartościowe, i może również przynieść trochę pieniędzy. Jeśli jednak zarobienie pieniędzy jest Twoim głównym celem, to myślę że inne sposoby na jego osiągnięcie są lepszym pomysłem.

Szczegóły, które pominąłem: Pomimo, że ten wpis miał opisać główne idee stojące za Bitcoinem, jest wiele szczegółów które ominąłem. Jednym jest sztuczka oszczędzająca miejsce używana przez protokół oparta na strukturze danych znanej jako drzewo Merkla/Merklego. To szczegół, ale okazały szczegół, i warty poznania, jeśli lubisz czytać o tego typu rozwiązaniach. Możesz przeczytać przegląd z oryginalnego referatu o Bitcoinie. Po drugie mało pisałem o sieci Bitcoin – tematy takie jak sieć radzi sobie z atakami DOS, jak węzły dołączają i opuszczają sieć i tak dalej. To fascynujący temat, ale równocześnie zawiera mnóstwo szczegółów, więc go ominąłem. Możesz o tych tematach poczytać w powyższych linkach.

Skrypty w protokole Bitcoin: W tym wpisie wyjaśniłem Bitcoin jako formę cyfrowej, internetowej waluty. Ale to tylko mała część większej i bardziej interesującej historii. Jak widzieliśmy, każda transakcja w siecie Bitcoin ma przydzielony skrypt w Bitcoinowym języku programowania. Skrypty, które widzieliśmy we wpisie opisują prostą transakcję jak „Ala przyznaje Bobowi 10 bitcoinów”. Ale język skryptowy może być również użyty do wyrażenia dużo bardziej skomplikowanych transakcji. Innymi słowy, Bitcoin to programowalna waluta. W następnych wpisach omówię język skryptowy i jak można użyć skryptów jako platforma do eksperymentowania z całym zbiorem zadziwiających instrumentów finansowych.

Dziękuję za uwagę. Jeśli zaciekawił Cię ten esej, być może zainteresuje Cię też pierwszy rozdział mojej książki, którą niedługo wydam o sieciach neuronowych i głębokim uczeniu, i rozważ wsparcie tej książki przez Indiegogo. Możesz również mnie zasubskryptować na Twitterze.

Przypisy

[1] W Stanach Zjednoczonych pytanie „Czy pieniądze to forma mowy?” to ważne zagadnienie prawne, ponieważ Konstytucja Stanów Zjednoczonych chroni wolność słowa. W mojej opinii (prawnie niedoinformowanej) cyfrowe waluty powodują, że odpowiedzenie na to pytanie jest jeszcze trudniejsze. Jak zobaczymy, protokół Bitcoin jest naprawdę sposobem nad powiedzenie całemu światu (albo przynajmniej reszcie sieci Bitcoin) „Zamierzam dać taką a taką ilość bitcoinów takiej a takiej osobie” w sposób, któremu później ekstremalnie trudno zaprzeczyć. Dla osób bez odpowiedniej wiedzy taka mowa wygląda bardziej na przemowę niż wymianę miedzianych monet.

Mirrory (serwery lustrzane, backup) artykułu:

http://dug.net.pl/tekst/260/opis_dzialania_obecnej_wersji_protokolu_sieci_bitcoin_/ http://dug.net.pl/tekst/260/opis_dzialania_obecnej_wersji_protokolu_sieci_bitcoin_/