„Größere Blöcke schließen Nutzer aus“ – Interview mit Bitcoin-Developer Dr. Christian Decker

Christian Decker ist ein Bitcoin-Developer der ersten Stunde und kann eine der ersten Doktorarbeiten über Bitcoin vorweisen. 2015 entwickelte er einen Ansatz, der dem Lightning Network sehr ähnlich ist. Entsprechend arbeitet er jetzt als Core Developer bei Blockstream. Grund genug, ihn bei der Unchain-Convention zu interviewen.

Dr. Philipp Giese
Teilen
Bitcoin-Developer Dr. Christian Decker

Beitragsbild: Anastasya Stolyarov

BTC-ECHO: Fangen wir mit einer einfachen Frage an: Wie bist du zu Bitcoin gekommen?

Christian Decker: Ich kam über mein Studium auf Bitcoin. Ich machte damals gerade meinen Master über verteilte Systeme und verteiltes Rechnen. Über Umwege bin ich Anfang 2009 auf das White Paper von Satoshi Nakamoto gestoßen. Das Paper, auch wenn ich nicht sofort alles verstand, faszinierte mich. Die Thematik war genau das, was ich später beruflich machen wollte. Und so habe ich den Austausch mit anderen aus der Bitcoin-Community gesucht. In dem Zusammenhang habe ich auch über bitcointalk mit Hal Finney und Satoshi Nakamoto diskutiert.

2012 stand ich vor der Frage, was ich als Thema für meine Doktorarbeit nehmen sollte. Vor dem Thema Bitcoin hatte ich mich ursprünglich gesträubt, schließlich war noch unklar, ob es dieses Phänomen bis zum Ende meiner Doktorarbeit geben würde. Nach einigem Hin und Her habe ich mich doch für das Thema Bitcoin entschieden, genauer gesagt für den Themenkomplex Skalierbarkeit.

BTC-ECHO: Um diese Skalierbarkeit drehte sich schließlich deine Doktorarbeit. Dein in der Arbeit vorgestellter Lösungsansatz ist off-chain, weshalb auch Adam Back dich als Erfinder des Lightning Network bezeichnet. Tatsächlich gab es damals ja ein Kopf-an-Kopf-Rennen zwischen einer Veröffentlichung von dir und Joseph Poon et al. Kannst du ein wenig dazu erzählen?

Christian Decker: An sich hatten wir das Paper sogar früher fertig, fielen aber den Mühlen der Reviewprozesse zum Opfer. Es war das letzte Paper im Rahmen meines Doktorates, wir wollten die Micropayment-Lösungen, die wir schon in Studentenprojekten entwickelt haben, niederschreiben.

Der Kerngedanke im Paper ist die Idee von bidirektionalen Payment-Channels. Mit diesen könnte ein Großteil der Bitcoin-Transfers bis auf das finale Settlement tatsächlich off-chain ablaufen.

Nach dem Submittal hatte ich natürlich einen Schock, als das Paper von Joseph und Tadge veröffentlicht war. Ich habe mir seine Arbeit angesehen und Stärken und Schwächen seines Ansatzes herausgearbeitet. Dieses Feedback haben wir noch in die Veröffentlichung eingearbeitet, nicht um die Idee von Josef und Tadge schlecht zu reden, sondern um uns davon zu distanzieren.

Nach der Doktorarbeit entschloss ich mich, mit dem Lightning-Team zusammenzuarbeiten. Es bringt nichts, zwei Mini-Lösungen zu haben, die nicht miteinander kompatibel sind. Man muss auch sagen, dass im Duplex-Microchannel-System, dem von mir verfolgten Ansatz, der On-Chain-Footprint größer ist. Nun nach drei Jahren Arbeit an Lightning, speziell im Rahmen von Blockstreams c-lightning, schließt sich der Kreis wieder. Im letzten Jahr haben wir das sogenannte eltoo-Paper veröffentlicht, in dem sich einige meiner damaligen Visionen niederschlagen. Mit etwas Glück schaffen wir, eltoo in die allgemeine Lightning-Spezifikation zu implementieren. Mit Roastbeef von Lightning Labs haben wir auch einen Co-Autoren jenseits von c-lightning mit an Bord, es soll also keine isolierte Lösung sein.

BTC-ECHO: Abgesehen vom On-Chain-Footprint auf der Bitcoin-Blockchain, wie unterscheidet sich denn der Duplex-Micropayment-Ansatz vom Lightning Network?

Christian Decker: Aktuell ist etwas in Lightning verbaut, was ich den „Lightning-Penalty-Mechanismus“ nenne. Ich erkläre diesen immer gerne mit einer Analogie. Sagen wir, ich gehe in ein Café. Ich lege 10 Euro auf den Tisch und kaufe mir einen Kaffee für einen Euro. Dem Barista steht damit ein Euro, mir neun Euro davon zu. Formell gesprochen initiiere ich eine Transaktion, in der der Barista einen Euro und ich neun Euro bekomme. Beim nächsten Kaffee lege ich eine neue Transaktion an. Diesmal eine, in der ich acht und der Barista zwei Euro erhält.

Nun muss man ein System schaffen, in welchem diese unterschiedlichen Transaktionen nicht miteinander vermischt wären. Es muss immer die aktuellste gültig sein. Ansonsten könnte ich den Ursprungszustand wiederherstellen. Ein Euro für einen Kaffee ist zwar schon preiswert, aber null Euro für zwei Kaffee wäre unschlagbar.

Bei Lightning werden alte Transaktionen für ungültig erklärt, indem jede Transaktion ein Hintertürchen hat. Durch dieses Hintertürchen kann ich meinen Gegenüber bestrafen, wenn er eine alte Transaktion für gültig erklärt, d. h. sie auf der Blockchain speichern will. Sollte ich also in obigem Bild versuchen, den Ursprungszustand wieder herzustellen und zu finalisieren, würde ich dem Barista die Möglichkeit geben, mir meine ganzen zehn Euro zu klauen.

So weit, so effizient. Problem mit diesem in Lightning verwendeten Ansatz ist jedoch, dass es auch zur Bestrafung Unschuldiger kommen kann. Wenn eine Transaktion verloren geht, kann es passieren, dass ein Nutzer aus Versehen eine alte Transaktion bestätigen möchte – und dafür bestraft wird. Backups können in der Hinsicht katastrophal sein. Sollte man nicht den jüngsten Zustand wiederherstellen, könnte das dazu führen, dass du all dein Geld verlierst. Das ist nicht selten – mir ist das auch schon passiert.

BTC-ECHO: Und dein Ansatz hat nicht dieses Problem?

Christian Decker: Genau. Bei eltoo und bei meinem ursprünglichen Ansatz gehen wir anders vor: Wir haben hier Lock-In und Effekt voneinander getrennt. Wenn eine Transaktion abgeschlossen werden soll, fängt ein Timer an, der mit dem Settlement bis zu einem Timeout wartet. In der Zeit kann der Gegenüber quasi Einspruch erheben. In obigem Café-Bild kann der Barista, sollte ich die Ursprungstransaktion nach zwei Kaffee finalisieren wollen, korrigierend eingreifen. Er würde zeigen, dass die aktuelle Transaktion eine ist, in der mir acht und ihm zwei Euro zustehen.

Und hier kommen wir zu etwas Interessantem: Derartige Transaktionen sind nicht umkehrbar. Ich kann also, haben wir uns mal auf die Aufteilung acht Euro / zwei Euro geeinigt, nicht einfach die Ursprungstransaktion wieder anführen. Der Prozess kann so lange fortgesetzt werden, bis entweder ich oder der Barista bis zum Timeout warten.

Bei eltoo entfernen wir also die Bestrafung. Vorteil ist dabei, dass man „im Zweifel für den Angeklagten“ ausgeht. Jemand, der aus Versehen einen alten Zustand ins System spielt, wird also einfach korrigiert und nicht bestraft. Außerdem muss nur der letzte Zustand gespeichert werden, was zu deutlich geringeren Anforderungen für Watchtower und ähnlichem führt.

Eine Schattenseite ist, dass eltoo ein Langzeitplan ist. Wir benötigen hierfür eine Änderung am Bitcoin-Protokoll selbst. Wir benötigen Schnorr-Signaturen für eine effiziente Implementierung.

BTC-ECHO: Ein gerne übersehener Aspekt bzgl. Dezentralität im Bitcoin-Ökosystem sind die unterschiedlichen LN-Approachs (C-Lightning, Lightning Labs, Eclair…). Wie unterscheidet sich C-Lightning von den anderen Ansätzen?

Christian Decker: Ich denke, man kann sagen, dass die unterschiedlichen Ansätze unterschiedliche Zielgruppen haben. Eclair beispielsweise zielt auf Nutzung von Mobiltelefonen ab. C-Lightning fokussiert sich im Kontrast dazu auf Low-Power-Devices und – im Extrem – auf Server. Lnd schließlich möchte sich eher auf Desktop-User fokussieren. Ein weiterer Unterschied ist, dass C-Lightning den Usern ein möglichst generelles, modifizierbares Handwerkszeug auf den Weg gibt, während Lnd eine fertige, schnell einsetzbare Lösung bieten will.

BTC-ECHO: Bitcoin hat sich, anders als Bitcoin SV und Bitcoin Cash, für eine Off-Chain-Skalierung entschieden. Jüngste Erfahrungen im BSV-Netzwerk mit einer 6-Block-Chain-Reorg geben dem Bitcoin-Ansatz ein wenig recht. Dennoch könnte man sagen, dass der Skalierungsansatz durch Erhöhung der Block Size einfacher ist. Was spricht gegen eine On-Chain-Skalierung? Ist nicht Moores Law auf Seiten der Big Blockers?

Christian Decker: Für mich ist eine der grundlegenden Eigenschaften Bitcoins die Trustlessness. Jeder soll sich darüber informieren können, was wann geschehen ist und damit im Besitz der zugrunde liegenden Daten sein. Dreht man die Anforderungen hoch, beispielsweise durch große Blöcke, schließt man Nutzer mit geringerem Speicher, schlechter performenden Computern oder einer geringeren Bandbreite aus. Deshalb würde ich Derartiges so lange wie möglich herauszögern.

Ein weiteres Problem ist, dass man eine Vergrößerung der Block Size nur über eine Hard Fork realisieren kann. Ein derartiger Schritt sollte in einem so großen Netzwerk wie dem von Bitcoin wohlüberlegt sein. Schließlich müsste man dann alle Peers zu dieser Hard Fork zwingen. Mal ganz davon abgesehen, dass dies schwer bis unmöglich ist, meiner Meinung nach widerspricht das der Ideologie von Bitcoin. Man würde jeden zu dieser Hard Fork zwingen. Jene, die vor mehreren Jahren Bitcoins kauften, aber seitdem liegen ließen, müssten nun aktiv werden. Inkompatible Änderungen sollten deshalb so lang wie möglich hinausgezögert werden.

Auf der anderen Seite kenne ich im Developer-Umfeld von Bitcoin niemanden, der eine Erhöhung der Blocksize langfristig komplett ausschließt. Meiner Meinung nach wird es irgendwann eine Blocksize-Vergrößerung geben, aber es sollte eine Ultima Ratio sein. Vorher sollten alle Alternativen ausgelotet sein, eben aus den oben genannten Gründen.

BTC-ECHO: Spricht sich der Bitcoin-Core-Developer Luke Dashjr nicht sogar für kleinere Blöcke aus?

Christian Decker: Er sagt, dass aktuell die Blöcke zu groß sind und reduziert werden können. Das Benutzerprofil, was ihm vorschwebt, würde davon stark profitieren. Er vertritt deshalb die Position, dass im ersten Schritt die Blöcke auf 300 kB verkleinert gehören, bevor man sie sukzessive vergrößert – jedenfalls verstehe ich ihn so.

BTC-ECHO: Kritiker von Off-Chain-Lösungen sagen, dass das Lightning Network, gemeinsam mit dem sinkenden Block Reward, für die Miner nach und nach negativ sein könnte. Igor von BlueWallet hat gesagt, es gäbe keinen Grund mehr, aus dem Lightning Network zu verschwinden. Das würde die Sorge der Lightning-Network-Kritiker bestätigen. Wie stehst du dazu?

Christian Decker: Da muss man als allererstes betonen: Das Lightning Network kann ohne die zugrundeliegende Blockchain nicht. Erst diese gibt ihr eine sichere Basis. Ein funktionierendes Bitcoin-Netzwerk ermöglicht ein sicheres Lightning Network. Deshalb überlegen wir auch und arbeiten daran, die Bitcoin-Blockchain für Miner weiterhin profitabel zu halten.

Dazu kommt, dass die Anforderungen Lightnings an das Bitcoin-Netzwerk deutlich höher sind als die von normalen Transaktionen. Wenn wir ein Settlement haben wollen, möchten wir, dass die damit verbundenen Transaktionen präferiert behandelt werden. Deshalb zahlen wir in der C-lightning-Implementation auch vergleichsweise hohe Gebühren – aktuell einen Faktor von fünf mehr als reguläre Transaktionen.

Außerdem sollte man dabei sehen, dass durch das Lightning Network Use Cases möglich werden, die bisher schlecht auf Bitcoin abbildbar waren. Mikro- und Nanopayments werden jetzt auf einmal möglich. Es erhöht sich also allgemein das Nutzungspotenzial. Sicher, ein klassisches Gegenargument ist, dass die in derartigen Prozessen gezahlten Gebühren Lightning Fees wären. Ein Teil davon fließt jedoch zu den Minern ab. In dem Sinne kann man sagen, dass Lightning nicht nur ein Transaktions- sondern auch ein Fee-Aggregations-Layer ist. Innerhalb der zwei On-Chain-Transaktionen, sprich dem Öffnen und dem Schließen des Payment-Channels, sind Tausende von Transaktionen inkludiert, von deren Fees immer etwas an die Miner fließt.

Die Theorie, dass wir bis in alle Ewigkeit unsere Kanäle offen lassen werden, halte ich für unrealistisch. Es wird immer wieder, sei es durch Risiko-Absicherung vor einem Stromausfall, zur Optimierung der eigenen Kanäle oder einfach zum finalen Settlement, Anreize zum Schließen eines Kanals geben.

BTC-ECHO: Schauen wir kurz in die Zukunft des Lightning Network. Jüngst gab es Überlegungen über die Monetarisierung von Watchtowern im Lightning Network. Kann man sich also vorstellen, dass es ähnlich wie im Bitcoin-Protokoll zu der Bildung eines Ökosystems mit verschiedenen Dienstleistungen kommt?

Christian Decker: Auf jeden Fall, es wird Dienstleistungen auf dem Lightning Network geben. Ein Beispiel wären Lightning-Router, die damit werben, ihre Kanäle oft zu schließen und damit ein Settlement realisieren. Ein anderes Beispiel sind die von dir genannten Watchtower, sprich Computer, die permanent online sind. Sie machen mobile Lightning Wallets möglich. Für derartige Dienstleistungen werden Leute sicherlich zahlen wollen. Klar, das Schöne bei Bitcoin ist, dass jeder das auch selber machen kann, aber dass Dienstleistungen angeboten werden, ist mehr als legitim. Nicht jeder möchte sich dermaßen intensiv mit Bitcoin beschäftigen.

Christian, vielen Dank für das Gespräch!

Du willst Uniswap (UNI) kaufen oder verkaufen?
Wir zeigen dir in unserem Leitfaden, wie und wo du einfach und seriös echte Uniswap (UNI) kaufen kannst.
Uniswap kaufen