Bitcoin Development Philosophy

Propozycja nie musi zawierać błędu programistycznego, by osłabić cały system. Może ułatwić obsługę przez powierzenie części weryfikacji zewnętrznej usłudze. Książka pomaga nazwać korzyści z tej wymiany i wskazać, komu zaczynamy ufać. Autorzy łączą objaśnienia z dawnymi debatami i wypowiedziami doświadczonych programistów. Czytelnik uczy się oceniać uzasadnienie pomysłu zamiast wybierać stronę ze względu na znane nazwisko. [2]

Trzeba rozumieć Proof of Work, czyli pracę wykazywaną podczas wydobycia, powstawanie bloków i drogę transakcji od rozgłoszenia do zapisania w łańcuchu. Dalej jest 9 głównych rozdziałów: decentralizacja, Trustlessness, prywatność, ograniczona podaż, aktualizacje, Adversarial thinking, otwarty rozwój, skalowanie i reagowanie na incydenty. To nie pierwszy poradnik kupowania bitcoina. Książka rozwija podstawy, pytając o znaczenie poszczególnych reguł i praktyk. [2] [1]

Trustlessness nie oznacza, że już nigdy nikomu nie ufamy. Jak wyjaśnia cytowany Pieter Wuille, chodzi o możliwość działania protokołu bez zaufanego pośrednika. Full Node, czyli węzeł wykonujący pełną weryfikację, sam sprawdzi, czy odebrany blok nie tworzy niedozwolonych monet lub nie wydaje dwukrotnie tej samej kwoty. Bez własnej weryfikacji zlecamy to komuś innemu. Węzeł nadal jednak działa na konkretnym oprogramowaniu i sprzęcie, które mogą mieć usterki. [3]

Wyobraź sobie płatność w bloku, który później zastępuje inna prawidłowa gałąź łańcucha. Taka zmiana historii to reorganizacja; może zmienić także status płatności. Rozdział, odwołując się do Davida Hardinga, oddziela kontrolę reguł od ochrony przed tym ryzykiem. Więcej potwierdzeń oznacza, że za blokiem pojawiły się kolejne bloki, co zwykle utrudnia jego zastąpienie. Nie jest to jednak obietnica, że własny węzeł powstrzyma każde przepisanie historii. [3]

Jeszcze przed sprawdzeniem płatności pojawia się pytanie: czy pobrany program odpowiada opublikowanemu kodowi źródłowemu? Powtarzalna kompilacja pozwala różnym osobom uzyskać identyczny plik z tych samych materiałów. Porównanie pomaga sprawdzić rozpowszechniany program. Rozdział przypomina jednak również wyjaśnienie Carla Donga: znaczenie ma pochodzenie narzędzi użytych do jego zbudowania. Zgodność plików nie dowodzi braku błędów w kodzie, kompilatorze ani komputerze. [3]

Adversarial thinking oznacza badanie propozycji z perspektywy przeciwnika. Pytamy nie tylko, czy działa przy uczciwym zachowaniu, lecz także co napastnik może zyskać, wykorzystując ją przeciw innym. Rozdział przywołuje Andrew Poelstrę i Jamesona Loppa, omawiając założenia bezpieczeństwa. Przykłady obejmują odcięcie węzła od uczciwej sieci i celowe zakłócanie otwartej współpracy. Dotychczasowe działanie systemu samo w sobie nie jest formalnym dowodem bezpieczeństwa całości. [4]

Cytowany aksjomat odporności Erica Voskuila opiera się na założeniu, że system może oprzeć się kontroli państwa. Aksjomat oznacza tu punkt wyjścia rozumowania, nie wynik testu dowodzącego niezniszczalności Bitcoina. To ważne również dla zwykłego czytelnika: sens poszukiwania odpornego rozwiązania nie oznacza, że każde nasze rozwiązanie wytrzyma wszystko. Książka podpowiada, jak rozpoznawać takie założenia i ograniczać przeoczenia. [4]

Przy każdym twierdzeniu pytaj, co sprawdzono, co pozostaje założeniem i jaką wygodę użytkownik zyskuje dzięki zmianie. Autorzy odsyłają do artykułów i wykładów; kopie artykułów z informacją o pochodzeniu przechowują oddzielnie w repozytorium. Ten przegląd opiera się na całym wstępie oraz pełnych tekstach Trustlessness i Adversarial thinking. Pozostałe rozdziały opisujemy według spisu treści. Nie jest to recenzja całej książki i wszystkich odsyłaczy ani wykonany audyt bezpieczeństwa. [2] [3] [4]