Reusable Proofs of Work

Am 15. August 2004 lud Hal Finney die Teilnehmer einer Kryptografie-Mailingliste ein, seinen neuen Versuch auszuprobieren. Er knüpfte an Hashcash von Adam Back an: Ein Computer probiert verschiedene Eingaben aus, bis ein Ergebnis eine festgelegte Bedingung erfüllt. Die Suche kostet Rechenzeit, die Prüfung des fertigen Ergebnisses geht schnell. Einen solchen Nachweis nennen wir Proof of Work, einen Arbeitsnachweis. Gegen Spam kann er wie eine mit Rechenarbeit bezahlte Briefmarke wirken. Finney interessierte, ob der Nachweis anschließend von Mensch zu Mensch wandern könnte, statt nach einmaliger Verwendung seinen Nutzen zu verlieren. Genau das bedeutet RPOW: wiederverwendbare Arbeitsnachweise. [1] [2] [4]

Anna besitzt einen gültigen digitalen Token und schickt ihn an Peter. Hat sie nur eine Datei übertragen, könnte sie eine Kopie behalten haben. Peter legt den Token deshalb dem RPOW-Server zum Umtausch vor. Der Server prüft, ob er noch unbenutzt ist, markiert ihn als verbraucht und signiert einen neuen, den Peters Programm vorbereitet hat. Annas Kopie des alten Tokens wird bei einem weiteren Umtausch abgewiesen. Peter kann den neuen später an Eva schicken, die den Vorgang wiederholt. Wiederverwendet wird also der übertragene Wert, nicht dieselbe dauerhaft gültige Datei. Solange der Empfänger den Umtausch nicht erfolgreich abgeschlossen hat, könnte der Absender den ursprünglichen Token noch vor ihm einlösen. [2] [11]

Als Eingabe diente entweder ein frisch berechneter Hashcash-Nachweis oder ein noch unbenutzter RPOW-Token. Heraus kam ein neuer Token mit einer digitalen RSA-Signatur, also einer mathematisch überprüfbaren Bestätigung des Servers. RSA ist ein Verfahren zur Berechnung einer solchen Signatur: Zum Erstellen dient ein geheimer Signaturschlüssel, zum Prüfen der zugehörige öffentliche Schlüssel. Es geht um überprüfbare Zahlendaten, nicht um das Bild einer handschriftlichen Unterschrift. Die Signatur belegte die Herkunft, sagte aber für sich allein nicht, ob der Token bereits umgetauscht worden war. Dafür gab es das Verzeichnis verwendeter Eingaben. Bei späteren Übertragungen musste niemand jedes Mal erneut die aufwendige Hashcash-Suche durchführen: Ein neuer Nachweis entstand gegen die Ungültigmachung des alten. Dabei wurde weder Strom wiederverwertet noch ein Anspruch auf bereits geleistete Arbeit kostenlos vervielfacht. [2]

Wert bezeichnete hier eine Stufe der Rechenschwierigkeit, keinen Preis in Kronen oder Dollar. Das damalige Hashcash verwendete SHA-1, eine Funktion, die aus Daten einen kurzen numerischen Fingerabdruck erzeugt. Gesucht wurde ein Fingerabdruck mit einer vorgegebenen Zahl führender Nullbits. Ein Bit ist eine einzelne Binärziffer. Jedes zusätzlich verlangte Nullbit verdoppelt ungefähr die durchschnittliche Zahl nötiger Versuche. Ein Token der Stufe 21 stand deshalb für dieselbe erwartete Arbeit wie zwei Token der Stufe 20 und ließ sich in sie aufteilen. Beim Zusammenlegen oder Aufteilen musste die Summe dieses Rechenarbeitswertes erhalten bleiben. Daraus folgten weder ein fester Wechselkurs noch garantierte Kaufkraft: Schnellere Computer konnten dieselbe Art von Token günstiger herstellen. [2] [10]

Double spend bedeutet, denselben Wert zweimal auszugeben. Dagegen benötigte RPOW ein Verzeichnis bereits eingetauschter Nachweise. Die vollständige Datenbank lag jedoch nicht in der geschützten Karte, sondern auf dem gewöhnlichen Hostcomputer. Die Karte behielt einen Prüffingerabdruck des Datenbankzustands und kontrollierte kryptografische Nachweise bei Abfragen. Dazu nutzte sie das Prinzip eines Merkle Tree: einen Baum aus Fingerabdrücken, mit dem sich einzelne Daten gegen einen gemeinsamen Fingerabdruck prüfen lassen. Erkannt werden sollten sowohl veränderte Einträge als auch die Rückkehr zu einer alten Datenbank, in der ein gerade eingelöster Token noch fehlt. Ohne diesen Schutz könnte der Betreiber dieselbe Eingabe wiederholt in neue Token umwandeln. [3]

Die sensiblen Operationen führte der Server in einer IBM 4758 aus, einer eigenständigen Computerkarte im gewöhnlichen Rechner. Sie sollte Signaturschlüssel und sensible Zustandsdaten selbst vor dessen Eigentümer schützen. Bei einem erkannten physischen Eingriff konnte sie geheime Daten löschen. Der Hostcomputer leitete Nachrichten weiter und speicherte die Datenbank, galt im Entwurf aber als nicht vertrauenswürdig. Darin lag Finneys Ansatz: Nur weil jemand den Server betrieb, sollte er nicht beliebig neue Token erzeugen können. Dieser Schutz setzte allerdings korrekte Hardware, ein korrektes Programm und geschützte Schlüssel voraus. Er war kein bedingungsloses Versprechen, das System sei unüberwindbar. [3] [9]

Offener Quellcode allein reicht nicht: Ein Betreiber könnte ein Programm zeigen und ein anderes ausführen. Deshalb verwendete RPOW remote attestation, eine Bestätigung der Konfiguration aus der Ferne. Die Karte stellte signierte Angaben zum laufenden Programm bereit. Interessierte konnten den veröffentlichten Quellcode mit passenden Werkzeugen kompilieren und den Fingerabdruck des entstandenen Programmabbilds mit dem gemeldeten vergleichen. Verglichen wurde also nicht einfach der Text einer Quelldatei. Das Vertrauen in die Signaturen führte über Zertifikate bis zu einem IBM-Schlüssel. So ließ sich besser prüfen, welches Programm tatsächlich lief. Fehlerfreiheit bewies das ebenso wenig wie die Unfehlbarkeit des Herstellers und seiner Zertifizierungsverfahren. [3] [9]

Durch den Tausch digitaler Token erinnert RPOW an eCash. Im ursprünglich beschriebenen Betrieb wurde die Privatsphäre jedoch nicht durch blindes Signieren geschützt. Finney setzte auf eine verschlüsselte Verbindung bis zur geschützten Karte und auf ein überprüfbares Programm, das keine Verknüpfungen zwischen ausgegebenen und empfangenen Token speicherte. Der Hostcomputer sollte deren Inhalt nicht im Klartext sehen. Er konnte aber weiterhin die Netzwerkadresse des Nutzers sowie Zeitpunkt und Umfang der Kommunikation beobachten. Auch die wiederholte Vorlage desselben Tokens konnte bestimmte Vorgänge verknüpfbar machen. Die erhaltene Dokumentation beschreibt bereits die Unterstützung von Tor. Dieses Netzwerk leitet Verbindungen über mehrere Zwischenstationen und verbirgt die ursprüngliche Netzwerkadresse des Nutzers vor dem Server. Blindes Signieren wird dagegen als mögliche spätere Ergänzung genannt. Diese geplante Funktion gehörte nicht zu dem damals beschriebenen Betrieb. [8] [10]

RPOW blieb nicht nur ein Entwurf auf Papier: Es gab einen laufenden Server und verfügbare Clientsoftware. Finney warnte allerdings von Anfang an vor dem frühen Versuchsstadium. Eine notwendige Änderung des Serverprogramms konnte zuvor ausgegebene Token ungültig machen. Vorgesehen waren persönliche, experimentelle und nicht kommerzielle Anwendungen, kein Geld mit garantiertem Wert. Auch eine geschützte Karte konnte den Betreiber nicht dazu zwingen, den Server eingeschaltet zu lassen. Das ursprüngliche Projekt ist beendet; erhaltene Seiten und Code sind historische Quellen. Die damalige Verwendung von SHA-1, RSA und Hardware ist daher keine Bauempfehlung für heutige Zahlungsdienste. [1] [4] [5] [7]

Finney wollte einen Teil von Nick Szabos Idee von Bit Gold praktisch zeigen: Die Herstellung eines digitalen Objekts kann aufwendig sein; anschließend lässt es sich weitergeben. Die RPOW-Dokumentation sah auch mehrere zusammenarbeitende Server vor. Den gesamten Entwurf auf einen für immer einzigen Computer zu reduzieren, wäre deshalb zu einfach. Ein konkreter Token legte jedoch fest, bei welchem Server er einzutauschen war; mehr Rechner beseitigten diese Abhängigkeit nicht von selbst. Bitcoin ging einen anderen Weg. Unabhängige Nodes, also Computer mit Prüfsoftware, kontrollieren gemeinsame Regeln und eine öffentliche Historie. Miner konkurrieren darum, weitere gültige Blöcke anzuhängen: Transaktionspakete, die mit dem vorherigen Eintrag verknüpft sind. RPOW verdeutlicht damit, was Proof of Work allein noch nicht löst: Wie erkennen alle die gültige Reihenfolge von Übertragungen, und wem müssen sie dabei vertrauen? [1] [6] [11]