Tadge Dryja

Stellen Sie sich vor, Knoten auf der ganzen Welt, also Computer, die Bitcoin-Regeln prüfen, müssten jeden bezahlten Kaffee einzeln prüfen. Wie wären mehr Zahlungen möglich, ohne für einen eigenen Knoten immer leistungsfähigere Computer zu benötigen? Joseph Poon und Thaddeus Dryja untersuchten dafür ein Netz aus Zahlungskanälen. Das verlinkte Whitepaper erläutert ihren Entwurf, trägt das Datum 14. Januar 2016 und die Kennzeichnung DRAFT 0.5.9.2. Es ist ein historischer Vorschlag. Er erklärt den Ursprung der Idee; heutige Programme und ihre genauen Regeln sind in deren eigener Dokumentation nachzulesen. [1]

Ein Zahlungskanal lässt sich als fortlaufend aktualisierte Vereinbarung über zuvor eingezahlte Bitcoin verstehen. Jede Zahlung verändert, welcher Anteil jeder Seite zusteht. Die Beteiligten signieren diese Änderungen, ohne jede einzeln in der Blockchain, der gemeinsamen Transaktionsgeschichte, zu veröffentlichen. Endet die Zusammenarbeit, lässt sich die Aufteilung durch eine Bitcoin-Transaktion durchsetzen. Lightning verlagert so viele Aktualisierungen aus der Blockchain, während die abschließende Abwicklung weiterhin auf den Regeln von Bitcoin beruht. [1]

Eine ältere Vereinbarung kann jemandem einen höheren Betrag zuweisen, obwohl davon inzwischen etwas ausgegeben wurde. Im beschriebenen Widerrufsmodell ermöglicht die Veröffentlichung eines ungültig gewordenen Zustands der anderen Seite eine Straftransaktion. Sie muss allerdings innerhalb einer festgelegten Frist reagieren. Deshalb muss ein Beteiligter oder ein beauftragter Dienst die Blockchain beobachten. Für den Alltag heißt das: Kryptografie allein macht eine dauerhafte Trennung ohne Überwachung nicht sicher. Verlässliche Beobachtung gehört zum Schutz der Mittel. [1]

Bitcoin kennt den Wechselkurs an einem vereinbarten Tag nicht von selbst. Discreet Log Contracts, kurz DLC, behandeln Verträge, deren Abwicklung von solchen Angaben abhängt. Zwei Beteiligte bereiten Bedingungen und mögliche Auszahlungen vor. Ein ausgewähltes Oracle, also eine externe Datenquelle, signiert später eine Mitteilung über das Ergebnis. Die Beteiligten nutzen sie für die passende Abwicklung. Das Oracle verwahrt in diesem Modell kein Geld der Parteien und muss nicht wissen, wer seine Mitteilungen verwendet. Es liefert Informationen, statt fremde Wallets zu verwalten. [2]

Eine digitale Signatur hilft festzustellen, wer eine Nachricht herausgegeben hat und ob sie verändert wurde. Ob die Angaben stimmen, beweist sie nicht. Ein Oracle kann einen falschen Kurs melden oder ganz schweigen. Für diesen Ausfall beschreibt Dryjas Entwurf eine vorab vorbereitete Rückzahlungstransaktion, die nach einer vereinbarten Frist veröffentlicht werden kann. Das Geld kommt nicht von allein zurück: Die Möglichkeit muss im Vertrag vorgesehen sein, und jemand muss sie nutzen. Eine zuverlässige Quelle und ein Plan für ihren Ausfall bleiben wichtig. [2]

Neben Zahlungskanälen untersuchte Dryja den Datenbedarf eines prüfenden Knotens. UTXO sind noch nicht ausgegebene Transaktionsausgänge: einzelne Beträge mit Bedingungen dafür, wie sie ausgegeben werden können. Utreexo stellt ihre Menge beim prüfenden Knoten durch eine kompakte kryptografische Zusammenfassung dar, einen Akkumulator. Zur Zahlung kommt ein Nachweis, dass der verwendete Ausgang zu dieser Menge gehört. Das spart Platz für den aktuellen Zustand. Es hebt weder die Regelprüfung auf noch schrumpft die gesamte Bitcoin-Geschichte auf eine winzige Datei. [4]

Auch die Utreexo-Nachweise müssen zum Prüfer gelangen. Ein kleinerer gespeicherter Zustand kann daher mehr Datenverkehr erfordern. Der Forschungsabstract beschreibt einen simulierten Blockchain-Download bis Anfang 2019: Bei 500 MB Cache, einem Zwischenspeicher für nützliche Daten, verursachten die Nachweise ungefähr 25 % zusätzliche Downloads. Die 500 MB sind nicht der gesamte Speicherbedarf des Knotens. Es handelt sich um ein bestimmtes Experiment, nicht um eine Zusage heutiger Anforderungen. Bei der Ersparnis zählen Festplattenspeicher, Arbeitsspeicher und Übertragung gemeinsam. [3]

In seiner bei MIT DCI veröffentlichten Erinnerung schildert Dryja einen ungezwungenen Beginn am MIT: Er brachte einen Computer mit, sprach über Bitcoin und half Studierenden. Direktorin Neha Narula fragte ihn daraufhin, ob er dort arbeiten wolle. Später unterrichteten sie gemeinsam. Im selben Abschiedstext kündigte er seinen Wechsel zu Lightspark an, um weiter an Bitcoin und Lightning zu arbeiten. Der Bericht hält einen bestimmten Lebensabschnitt fest und belegt keine heutige Beschäftigung. Veröffentlichungen, Code und verständlich erklärte Ideen zeigen seinen Beitrag besser als eine einzelne Stellenbezeichnung. [5]