Reusable Proofs of Work

15 sierpnia 2004 roku Hal Finney zaprosił uczestników listy dyskusyjnej o kryptografii do wypróbowania nowego eksperymentu. Nawiązywał do Hashcash Adama Backa: komputer próbuje różnych danych wejściowych, aż znajdzie wynik spełniający ustalony warunek. Poszukiwanie kosztuje czas obliczeń, a sprawdzenie gotowego wyniku jest szybkie. Taki dowód nazywamy Proof of Work, dowodem pracy. W ochronie poczty przed spamem może działać jak znaczek opłacony obliczeniami. Finneya interesowało, czy dowód mógłby potem przechodzić z rąk do rąk, zamiast tracić użyteczność po jednym wykorzystaniu. Właśnie to znaczy nazwa RPOW: dowody pracy wielokrotnego użytku. [1] [2] [4]

Wyobraźmy sobie, że Anna ma ważny cyfrowy żeton i wysyła go Piotrowi. Jeśli przekazała jedynie plik, mogła zachować jego kopię. Piotr przedstawia więc żeton serwerowi RPOW i prosi o wymianę. Serwer sprawdza, czy żeton nie został wcześniej użyty, oznacza go jako zużyty i podpisuje nowy, przygotowany przez program Piotra. Kopia starego żetonu u Anny nie przejdzie już kolejnej wymiany. Piotr może wysłać nowy żeton Ewie, która powtórzy procedurę. Ponownie wykorzystuje się zatem przekazywaną wartość, a nie wciąż ten sam ważny plik. Dopóki odbiorca nie zakończy wymiany, nadawca może jeszcze wydać pierwotny żeton przed nim. [2] [11]

Na wejściu mógł pojawić się świeżo obliczony Hashcash albo jeszcze nieużyty żeton RPOW. Wynikiem był nowy żeton z podpisem cyfrowym RSA, czyli matematycznie sprawdzalnym potwierdzeniem serwera. RSA to metoda obliczania takiego podpisu: do jego utworzenia służy tajny klucz podpisu, a do sprawdzenia odpowiadający mu klucz publiczny. To sprawdzalne dane liczbowe, nie obraz odręcznego podpisu. Podpis pozwalał zweryfikować pochodzenie żetonu, lecz sam nie mówił, czy ktoś już go wymienił. Do tego służył rejestr wykorzystanych wejść. Przy następnych przekazaniach nie trzeba było za każdym razem ponawiać kosztownego szukania Hashcash: nowy podpis otrzymywano w zamian za unieważnienie starego dowodu. Nie był to recykling prądu ani sposób na darmowe mnożenie roszczeń do wcześniej wykonanej pracy. [2]

Wartość oznaczała poziom trudności obliczeniowej, nie cenę w koronach czy dolarach. Ówczesny Hashcash korzystał z SHA-1, funkcji tworzącej krótki liczbowy odcisk danych, i szukał odcisku z określoną liczbą początkowych bitów zerowych. Bit to jedna cyfra binarna. Każde dodatkowe wymagane zero w przybliżeniu podwaja średnią liczbę prób. Żeton poziomu 21 reprezentował więc taką samą oczekiwaną pracę jak dwa żetony poziomu 20 i można go było na nie podzielić. Łączenie i dzielenie musiało zachowywać sumę tej wartości obliczeniowej. Nie oznaczało to stałego kursu ani gwarantowanej siły nabywczej: szybsze komputery mogły wytwarzać żetony tego samego typu taniej. [2] [10]

Double spend oznacza dwukrotne wydanie tej samej wartości. Aby temu zapobiec, RPOW potrzebował listy już wymienionych dowodów. Cała baza nie znajdowała się jednak wewnątrz chronionej karty: przechowywał ją zwykły komputer, w którym zamontowano kartę. Karta zachowywała kontrolny odcisk jej stanu i przy zapytaniach sprawdzała dowody kryptograficzne. Wykorzystywała zasadę Merkle Tree, drzewa odcisków pozwalającego sprawdzić część danych względem jednego wspólnego odcisku. Chodziło o wykrycie zarówno zmian w zapisach, jak i powrotu do starej bazy, w której nie ma jeszcze właśnie wydanego żetonu. Bez tej ochrony operator mógłby wielokrotnie zamieniać to samo wejście na nowe żetony. [3]

Wrażliwe operacje serwer wykonywał wewnątrz IBM 4758, samodzielnej karty komputerowej umieszczonej w zwykłym komputerze. Miała chronić klucze podpisu i dane istotne dla bezpieczeństwa nawet przed właścicielem tego komputera. Po wykryciu ingerencji fizycznej mogła usunąć tajne dane. Komputer z zainstalowaną kartą przekazywał wiadomości i trzymał bazę, ale projekt nie traktował go jako zaufanego. To było sedno pomysłu Finneya: samo uruchomienie serwera nie miało pozwalać operatorowi na dowolne tworzenie żetonów. Ochrona zależała jednak od poprawnego sprzętu, programu i zabezpieczenia kluczy. Nie była bezwarunkową obietnicą niemożności przełamania systemu. [3] [9]

Samo opublikowanie kodu źródłowego nie wystarcza: operator może pokazywać jeden program, a uruchamiać inny. RPOW stosował więc remote attestation, zdalne potwierdzenie konfiguracji. Karta wydawała podpisane informacje o wykonywanym programie. Zainteresowana osoba mogła skompilować udostępniony kod odpowiednimi narzędziami i porównać odcisk powstałego obrazu programu z odciskiem zgłoszonym przez kartę. Nie porównywano zatem po prostu tekstu pliku źródłowego. Zaufanie do podpisów prowadziło przez łańcuch certyfikatów do klucza IBM. Pomagało to sprawdzić, jaki program rzeczywiście działa, ale nie dowodziło braku błędów w kodzie ani nieomylności producenta i jego procedur certyfikacji. [3] [9]

RPOW przypomina eCash przez wymianę cyfrowych żetonów, ale pierwotnie opisany system nie chronił prywatności ślepym podpisywaniem. Finney polegał na szyfrowanym połączeniu aż do chronionej karty i sprawdzalnym programie, który nie zapisywał powiązań między wydanymi a odebranymi żetonami. Komputer z zainstalowaną kartą nie miał widzieć ich jawnej treści. Nadal jednak mógł obserwować adres sieciowy klienta, czas i rozmiar komunikacji. Ponowne przedstawienie tego samego żetonu również pozwalało połączyć pewne zdarzenia. Zachowana dokumentacja opisuje już obsługę Tor, sieci kierującej połączenie przez kilka węzłów pośredniczących i ukrywającej przed serwerem pierwotny adres sieciowy użytkownika. Ślepe podpisy przedstawia natomiast jako możliwy późniejszy dodatek. Tej planowanej funkcji nie należy przypisywać opisanemu wówczas sposobowi działania. [8] [10]

RPOW nie pozostał propozycją na papierze: miał działający serwer i dostępny program kliencki. Finney od początku ostrzegał jednak, że to wczesna wersja próbna. Konieczna zmiana oprogramowania serwera mogła unieważnić wcześniej wydane żetony. Projekt przeznaczał je do zastosowań osobistych, eksperymentalnych i niekomercyjnych, nie jako pieniądz z gwarantowaną wartością. Nawet chroniona karta nie mogła zmusić operatora, by pozostawił serwer włączony. Pierwotny projekt zakończono; zachowane strony i kod są materiałami historycznymi. Opis ówczesnego SHA-1, RSA i sprzętu nie jest więc zaleceniem budowy dzisiejszego systemu płatniczego w ten sposób. [1] [4] [5] [7]

Finney chciał pokazać w praktyce część idei Bit Gold Nicka Szabo: cyfrowy przedmiot może być kosztowny w wytworzeniu, a później nadawać się do przekazywania. Dokumentacja RPOW przewidywała też współpracę wielu serwerów, więc sprowadzenie całego projektu do jednego komputera na zawsze byłoby uproszczeniem. Konkretny żeton wskazywał jednak serwer, na którym należało go wymienić; dodatkowe maszyny same nie usuwały tej zależności. Bitcoin wybrał inną drogę. Niezależne węzły, czyli komputery z oprogramowaniem weryfikującym, sprawdzają wspólne reguły i publiczną historię. Górnicy konkurują o dodawanie kolejnych prawidłowych bloków: pakietów transakcji połączonych z poprzednim zapisem. RPOW pomaga zrozumieć, czego sam Proof of Work jeszcze nie rozwiązuje: jak wszyscy rozpoznają prawidłową kolejność przekazań i komu muszą przy tym ufać. [1] [6] [11]