Reusable Proofs of Work (RPOW)

Neugier

1. Wie kann man einer zentralen Instanz vertrauen, dass sie nicht betrügt, wenn sie das Ledger kontrolliert?
2. Warum scheiterte ein System mit überprüfbarem Code dennoch als Geld?
3. Wenn niemand einen Server betrügen kann, was kann dann noch schiefgehen?

Erkunden

1. Im August 2004 veröffentlichte Hal Finney Reusable Proofs of Work (RPOW), einen Prototyp für digitales Geld, der Adam Backs Hashcash weiterentwickelte. Während frühere Stempel an einzelne Empfänger gebunden und nicht übertragbar waren, ließen sich RPOW-Token beim Server eins zu eins gegen neue Token tauschen. So konnte Wert beliebig oft von Person zu Person weitergegeben werden – ähnlich wie physisches Bargeld, aber unter Beibehaltung der Rechenkosten bei der Erzeugung.
2. Das zentrale Vertrauensproblem war die Zentralisierung: Ein einziger Server verwaltete alle Guthaben und verhinderte Double Spending, indem er eine Liste der ausgegebenen Token führte. Um dies abzumildern, implementierte Finney Remote Attestation mithilfe eines IBM 4758 Secure Cryptographic Coprocessor. Diese manipulationssichere Hardware ermöglichte es jedem externen Nutzer zu prüfen, dass der Server genau den veröffentlichten Open-Source-Code wie vorgesehen ausführte, sodass nicht einmal der Betreiber die Regeln heimlich ändern konnte.
3. Technisch reichte ein Nutzer einen Proof of Work im Stil von Hashcash beim Server ein und erhielt im Gegenzug ein RSA-signiertes RPOW-Token. Bei einer Zahlung übergab der Sender das Token an den Empfänger, der es beim Server gegen neue Token gleichen Werts einlöste. Dieser Ablauf stellte sicher, dass jede Werteinheit einzigartig und unverbraucht blieb, und löste so das Double-Spending-Problem innerhalb einer geschlossenen, vertrauenswürdigen Umgebung.
4. Token ließen sich auf dem Server teilen und zusammenführen, solange der Gesamtwert erhalten blieb. Eine Einschränkung war ökonomischer Natur: Nichts glich schnellere Hardware aus. Da Rechenleistung billiger wurde, kostete es weniger Arbeit, ein Token einer bestimmten Größe zu erzeugen, als ein früher erzeugtes, sodass Token mit gleichem Nennwert ungleiche Kosten verkörperten.
5. Die Ein-Server-Architektur blieb ein Single Point of Failure. Remote Attestation verhinderte zwar Betrug durch den Betreiber, konnte aber weder eine Abschaltung noch eine Netzwerkpartitionierung verhindern. Das System musste für alle Transaktionen ständig verfügbar sein und war damit so anfällig wie sein Host. Diese Abhängigkeit von einer zentralen Instanz unterschied RPOW von späteren dezentralen Protokollen, die den Konsens auf viele unabhängige Nodes verteilten.
6. Finneys Design kam elektronischem Bargeld vor Bitcoin am nächsten: Es verband die Ausgabe per Proof of Work mit übertragbaren Token. Genutzt wurde es kaum: Nur wenige Menschen hatten einen Grund, die Token zu halten, und nur wenige Stellen akzeptierten sie. Der Schritt von RPOW zu Bitcoin bestand darin, den vertrauenswürdigen zentralen Server durch einen verteilten Konsensmechanismus zu ersetzen, der probabilistische Finalität statt absoluter Gewissheit akzeptierte.

Kernfakten

Übung neun, sechs, drei, eins

Faktcheck

Datumsangaben, Zahlen und Behauptungen wurden mit den unten aufgeführten veröffentlichten Quellen abgeglichen.

• H. Finney, 'Reusable Proofs of Work' documentation (rpow.net, 2004)
• N. Popper, Digital Gold: Bitcoin and the Inside Story of the Misfits and Geniuses Trying to Reinvent Money (2015)
• A. Back, 'Hashcash – A Denial of Service Counter-Measure' (2002)