395 / 736CORALLO

Matt Corallo

Als TheBlueMatt bekannter Entwickler

Wenn ein neuer Bitcoin-Block entsteht, müssen die anderen Rechner davon erfahren. Matt Corallo arbeitete daran, diese Daten mit weniger Bandbreite und Verzögerung zu übertragen. Außerdem half er beim Aufbau von Software, mit der Entwickler Lightning-Anwendungen erstellen.

Matt Corallo, bekannt als TheBlueMatt, ist ein Bitcoin-Entwickler, dessen Arbeit mit Compact Block Relay, dem Übertragungsnetz FIBRE und rust-lightning verbunden ist. Dahinter steht eine praktische Frage: Wie verbessert man Netze und Anwendungen, ohne Geschwindigkeit mit der Gewissheit zu verwechseln, dass alles korrekt ist?

Auf GitHub tritt Matt Corallo als TheBlueMatt auf. Sein Profil weist darauf hin, dass viele Repositories nach git.bitcoin.ninja umgezogen sind. Ein Repository enthält Quellcode und dessen Änderungshistorie. Ein verwaister alter Speicherort bedeutet deshalb nicht unbedingt, dass das Projekt aufgegeben wurde. Wer die Beiträge einzelner Menschen nachvollziehen möchte, sollte diese Historie, die Vorschläge und deren Autoren ansehen. Bei Corallo führt das von effizienterem Blocktransport zu Werkzeugen für Lightning. [1]

Rechner, die Bitcoin prüfen, tauschen laufend unbestätigte Transaktionen aus. Trifft ein neuer Block ein, kennen sie daher oft bereits einen großen Teil seines Inhalts. Compact Block Relay nutzt das aus. Die öffentliche technische Spezifikation BIP 152 nennt Corallo als Autor und dankt Gregory Maxwell für die erste Idee, Entwurfsarbeit und Tests. Vorrangig soll das Datenvolumen sinken. Die Übertragung kann dadurch auch schneller werden, doch die Gültigkeitsregeln für Blöcke bleiben unverändert. [2]

Stellen Sie sich eine gemeinsame Dokumentenliste vor: Die meisten Dokumente besitzen Sie schon und müssen nur erfahren, welche zum neuen Paket gehören. Ähnlich nutzt BIP 152 kurze Transaktionskennungen und den Mempool, den lokalen Vorrat unbestätigter Transaktionen. Fehlende Daten fordert der Empfänger mit getblocktxn an. Kennungen können kollidieren, also verschiedene Transaktionen gleich bezeichnen. Die Bandbreitenersparnis ersetzt daher weder die vollständigen Daten noch die Prüfung, ob der richtige Block rekonstruiert wurde. [2]

Unter festgelegten Bedingungen erlaubt BIP 152 eine kompakte Ankündigung, bevor der Sender sämtliche Transaktionen vollständig geprüft hat. Beliebige Daten darf er trotzdem nicht weiterreichen: Blockkopf, Anschluss an die geprüfte Kette, Arbeitsnachweis und Bindung an die enthaltenen Transaktionen müssen geprüft sein. Nach der Rekonstruktion wird der Block wie gewohnt verarbeitet. Der Empfänger prüft weiterhin, ob vorhandene Mittel regelkonform ausgegeben werden. „Block angekommen“ ist etwas anderes als „Block gültig“. [2]

Im Internet reisen Daten in kleinen Paketen. Geht eines verloren, kostet das Warten auf eine erneute Übertragung Zeit. Am 7. Juli 2016 beschrieb Corallo FIBRE: Es verbindet kompakte Blöcke mit UDP, einem Transport ohne automatische Wiederholung verlorener Pakete, und FEC, einer Codierung zur Wiederherstellung fehlender Teile. Zusätzliche Daten helfen, den Inhalt ohne erneute Anfrage zu rekonstruieren. Dafür wird insgesamt mehr übertragen; fehlerfreie Übertragung unter allen Umständen wird damit nicht garantiert. [3]

FIBRE kann einzelne Pakete schon vor ihrer Prüfung weiterleiten. Das spart Zeit, setzt innerhalb des Netzes aber starkes Vertrauen zwischen den betriebenen Knoten voraus. Beliebige ungeprüfte Verbindungen sind damit nicht gemeint. Offener Code ermöglicht weitere Netze; der Betreiber eines konkreten Netzes kann dennoch seine Gegenstellen auswählen. Laut FAQ übernahmen w0xlt und Justin von Localhost Research im Jahr 2025 die Wartung, beraten von Corallo und Maxwell. Andere Menschen führen die Arbeit also fort. [4]

Ein weiterer Teil von Corallos Arbeit betrifft Lightning, ein Netz für Zahlungen über Kanäle auf Bitcoin. Das Manifest, also die Paketbeschreibung, von lightning in rust-lightning führt Matt Corallo als Autor auf. Die in Rust geschriebene Bibliothek stellt grundlegende Lightning-Funktionen bereit. Anwendungen können Wallet, Blockchain-Anbindung, Speicherung und Netzwerk selbst gestalten. Der Autorenvermerk bedeutet aber weder, dass eine Person jede spätere Änderung schrieb, noch dass die Bibliothek allein eine fertige Wallet ist. [5]

LDK wird als SDK in die Anwendung eingebaut, also als Werkzeugkasten für Entwickler. Diese müssen Speicherung und weitere benötigte Komponenten verbinden. Das Ergebnis einer Zahlung kommt nicht zwingend beim Start zurück: LDK meldet Erfolg oder Misserfolg später über ein Ereignis, das die Anwendung verarbeitet. Das Auslösen bestätigt also noch keinen Erfolg. Für den Menschen mit der Wallet folgt daraus eine einfache Anforderung: Die Anzeige muss eine laufende Zahlung von einer abgeschlossenen unterscheiden. [6]

Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit Gregory Maxwell, Luke Dashjr, Satoshi Nakamoto. Auf diesen Eintrag verweisen außerdem Stratum V2, Gregory Maxwell, Luke Dashjr.

DOC · 001GitHub — Matt CoralloDokumentation DOC · 002BIP 152 — Compact Block RelayDokumentation DOC · 003Matt Corallo — The Future of The Bitcoin Relay NetworksDokumentation DOC · 004FIBRE — FAQDokumentation DOC · 005rust-lightning — package manifestDokumentation DOC · 006LDK — ArchitectureDokumentation
Überarbeitet: Quellenbasiert · Keine Anlageberatung