Blockchain

Von Offchain zu Offchain: Statechains trifft Lightning

Das Lightning-Netzwerk ist die klar wichtigste Offchain-Lösung für Bitcoin. Doch in seinem Schatten hat sich mit der Statechain mittlerweile eine interessante Alternative entwickelt. Nun gibt es einen Vorschlag, um die beiden Offchain-Netzwerke zu verbinden.

Wenn ihr auf eine Wasseroberfläche schaut, sagen wir, von einem Meer, dann seht ihr Wellen, die sich kräuseln, vielleicht eine Qualle, die zum Licht treib, und Sonnenstrahlen, die sich gleißend im Wasser spiegeln.

Doch ihr seht nur einen winzigen Teil. Von der Oberfläche bis zum Meeresgrund sind es hunderte von Metern. Darin schwimmen Dutzende Fischarten, am Boden krabbeln Krebse und Seesterne, an Steinen kleben Muscheln, und Meerespflanzen ranken sich nach oben. Dort, wo sich euer Blick bricht, beginnt erst eine ganz eigene Welt.

Und genau so, wie das Meer, kann man sich eine Blockchain wie Bitcoin vorstellen. Das, was man auf der Oberfläche sieht, ist nur ein Bruchteil von dem, was drin stecken kann; das, was die Full Nodes speichern, nämlich die Historie aller Transaktionen und das Set der UTXOs (Coins), ist lediglich der Einstieg in eine Welt, in der viel mehr passiert.

Zumindest ist so der Plan. Bei Bitcoin ist es vor allem das Lightning, das als „Layer 2“ auf der Blockchain aufsitzt und Transaktionen „offchain“ transportiert. Doch Lightning ist nicht die einzige dieser Schichten unter der Oberfläche. Eine andere ist die Statechain. Sie ist jünger, experimenteller und noch weniger genutzt. Aber sie funktioniert bereits.

Mittlerweile gibt es sogar einen Vorschlag, Statechain mit Lightning kombinieren, was eine aufregende Vorstellung ist. Doch bevor wir dahin kommen, sollten wir erst einmal erklären, was eine Statechain ist.

Statechains: Schlüssel übergeben anstatt Bitcoins überweisen

Die Kernidee der Statechain ist die Folgende: Man versendet Bitcoins nicht durch eine Blockchain-Transaktion – sondern indem man den privaten Schlüssel übergibt. So ähnlich, wie es die legendären Münzen machen, die man früher als Bild von jedem zweiten Artikel über Bitcoin sah.

Die Nachteile liegen auf der Hand: Wenn ich dir meinen privaten Schlüssel sende, gibt es keine Garantie, dass ich ihn nicht behalte. Um dir sicher zu sein, müsstest du gleich eine Transaktion bilden, um die Bitcoins auf eine neue Adresse zu senden, für die nur du die privaten Schlüssel hast. Dann aber hätten wir das mit der Schlüsselübergabe gleich lassen können.

Der Bitcoin-Entwickler Ruben Somsen hat bereits 2018 eine Methode vorgeschlagen, um das Problem zu entschärfen: Der Bitcoin wird in eine 2-von-2-Multisig-Adresse gelegt, so dass er nur bewegt werden kann, wenn zwei Schlüssel die Transaktion signieren. Der eine Schlüssel gehört mir, und ich sende ihn wie gehabt dir anstelle einer Transaktion. Der zweite Schlüssel dagegen ist im Besitz einer neutralen Partei, die die Statechain verwaltet. Sie muss eine Transaktion mitsignieren, wenn der letzte Besitzer des übergebenen Schlüssels darum bittet.

Aber woher weiß die neutrale Partei, wer der letzte Besitzer des Schlüssels ist? Das ist relativ einfach: Der Sender erzählt es ihr, und sie erzählt es dem Empfänger. Zugleich unterschreibt der Sender eine Nachricht, dass er den Schlüssel an den Empfänger sendet, und so weiter. So entsteht eine öffentliche Mini-Blockchain, die dokumentiert, wer der rechtmäßige Besitzer ist. Dies hindert die neutrale Partei nicht daran, zu betrügen, aber macht es immerhin öffentlich.

Für den Fall schließlich, dass die neutrale Partei abtaucht oder ihre Schlüssel verliert, bildet der Sender eine Backup-Transaktion, welche die Coins von der Multisig-Adresse an eine neue Adresse sendet, aber erst, wenn eine gewisse Zeit verstrichen ist. Diese Transaktion wird von der neutralen Partei signiert – bevor der Sender die Coins auf der Multisig-Adresse ablegt. Um zu verhindern, dass ich nun rückwirkend die Coins an mich zurückzahle, bildet der Empfänger eine analoge Transaktion, die meine überschreiben kann.

Die Details sind komplex, die Konstruktion erinnert an die Payment Channels bei Lightning.

Die erste Implementierung durch Mercury

Als Ruben Somsen 2018 Statechains vorstellte, fehlten noch zwei Elemente im Bitcoin-Protokoll, um die Statechains umzusetzen: Schnorr, für die Multisig-Konstruktion, und Sighash_Anyprevout, eine spezielle Art, die Signatur zu hashen.

Mit Taproot wurde Schnorr aktiviert, doch Sighash_Anyprevout wartet noch auf die Aktivierung durch eine Softfork. Es gibt zwar ein ausführliches BIP, doch es scheint noch in der Diskussion zu sein. Zumindest ist bisher kein Termin angepeilt, an dem es aktiviert werden soll.

Um Statechains aber dennoch zu ermöglichen, haben die Entwickler von CommerceBlock 2020 begonnen, eine Variante umzusetzen, die ohne Sighash_Anyprevout auskommt. Dabei verwenden sie eine clevere nLocktime-Konstruktion namens Mercury: Die Backup-Transaktionen werden erst bei einer gewissen Blockhöhe X gültig. Die erste Backup-Transaktion bei X, die zweite bei X-1, die dritte bei X-2 und so weiter. So kann der gegenwärtige Besitzer im Falle eines Betrugsversuchs die Bitcoins immer als erstes an sich selbst auszahlen.

Mit der Mercury Wallet hat CommerceBlock dieses Konzept umgesetzt. Die Mercury Wallet ergänzt dies durch CoinSwaps, durch die User ihre eigenen Coins anonym gegen die Coins anderer User tauschen können. Dies ist eine etwas tollkühne, aber interessante Methode, um die Privatsphäre zu verbessern – tollkühn, weil man mit etwas Pech hochschmutzige Bitcoins bekommt.

Statechain trifft Lightning

Nicht minder kühn ist nun das BLIP, das CommerceBlock eingereicht hat. Ein BLIP meint ein „Bitcoin Lightning Improvement Proposal“, also einen Vorschlag, um Lightning zu verbessern.

CommerceBlock schlägt vor, Lightning mit Statechain zu verbinden: Es soll möglich werden, einen Lightning-Channel zu bilden, ohne dafür eine Onchain-Transaktion zu senden, sondern durch ein Statechain-Guthaben.

Dazu muss der Sender der Statechain-Transaktion lediglich eine Transaktion bilden, die mit dem Inhalt der Statechain-Adresse einen Lighting-Channel aufbaut, mit all den Details und Smart Contracts, die zu Lightning gehören.

Diese Verbindung erlaubt es auf der einen Seite, eine Begrenzung der Statechain zu überkommen: Anstatt den kompletten Coin auszugeben – was bei einer Schlüsselübergabe an sich unvermeidbar ist – kann man innerhalb des Payment Channels auch Bruchteile der Münze überweisen. Auf der anderen Seite wird es möglich, einen Payment-Channel über eine Statechain an jemand anderes zu transferieren.

Von einer höheren Perspektive aus betrachtet – sagen wir, von der Oberfläche des Meeres aus – hätte die Verbindung von Statechains und Lightning mehrere Vorteile: Sie würde es erstens erlauben, Lightning weiter zu skalieren, da nicht länger Onchain-Transaktionen nötig wären, um einen Lightning-Channel zu öffnen. Zweitens würden sie die Privatsphäre verbessern, da sie die Spur brechen können, welche einen Lightning-Channel mit der Wallet der User verbindet.

Ungelegte, aber interessante Eier

Natürlich reden wir hier noch über ungelegte Eier. Während Lightning sich einer wachsenden Verbreitung erfreut, scheinen Statechains noch ein Nischenleben zu führen, das um CommerceBlocks bzw. Mercury herum zentralisiert ist. Laut dem Mercury-Blockexplorer gibt es alle paar Stunden, teils auch nur alle paar Tage, eine Statechain-Transaktion.

Auch ob das BLIP implementiert wird, ist noch fraglich. Lightning ist ohnehin schon komplex, so dass noch mehr Komplexität derzeit vielleicht eher schädlich als nützlich ist. Wie sollten Wallet-Entwickler so etwas jemals umsetzen? Wie gehen Börsen damit um?

Trotz all dem zeigt der Vorschlag eines ziemlich deutlich: Unter der Oberfläche der Bitcoin-Blockchain kann ein ganzes Universum von Offchain-Schichten wachsen.

   

Source


Show More
Close

Werden Sie Millionär, indem Sie mit Crypto handeln!