Forscher von [[alloc] init] – Clara Shikhelman, Misha Komarov und Aleksei Moskvin – haben Shielded Bitcoin veröffentlicht, ein Whitepaper, das ein neuartiges Privacy-Metaprotokoll auf der Bitcoin-Basisebene beschreibt. Das Design ermöglicht geschützte Bitcoin-Transaktionen ohne Operatoren, Soft Forks oder sonstige Änderungen am Bitcoin-Konsens. Das Whitepaper und eine begleitende Blog-Ankündigung sind verfügbar; das Team hat die Nachricht auf X geteilt.

Das Protokoll definiert eine Transaktionsstruktur und ein Indexierungsprotokoll für stark privatsphärewahrende Transaktionen und stützt sich dabei auf Bitcoin PIPEs, um Mittel in das System hinein und aus ihm heraus zu pegen. Der PIPEs-Mechanismus wird am Ende dieses Artikels ausführ untersucht.

Die Eigenschaft, keine Konsensänderung zu benötigen, ist bedeutsam: Bitcoins Ledger zeichnet Beträge und Adressen öffentlich auf, und Änderungen seiner Regeln erforderten historisch eine breite netzweite Koordination. Ein Design, das vollständig innerhalb des bestehenden Regelwerks funktioniert, hängt nicht von diesem Prozess ab, um voranzukommen.

Ein Bitcoin-ähnliches Design mit sehr unterschiedlichen Details

Die Architektur spiegelt bewusst Bitcoin selbst wider. Es gibt ein Äquivalent zum UTXO, das Note genannt wird. Transaktionen konsumieren Notes als Inputs, so wie eine reguläre Bitcoin-Transaktion UTXOs ausgibt. Ein Witness belegt, dass die konsumierten Inputs ordnungsgemäß autorisiert sind, und Nodes – im Fall eines Metaprotokolls Indexer – parsen die Transaktionshistorie und bauen einen laufenden Zustand darüber auf, welche Coins ausgegeben und welche unverbraucht sind.

Jedes zugrunde liegende Detail unterscheidet sich jedoch erheblich.

Transaktionen, die Bitcoin selbst ignoriert

Eine Shielded-Bitcoin-Transaktion ist schlicht ein Datenblob mit einem Präfix – etwa „shbtc:“ –, der über OP_RETURN, das Witness-Feld oder eine andere Methode zur Datenübertragung in eine Bitcoin-Transaktion eingebettet wird. Dies ist das Metaprotokoll-Muster: Die Regeln des Protokolls werden von seinen eigenen Indexern durchgesetzt, nicht von Bitcoin; die Basiskette sieht nichts anderes als gewöhnliche Daten. Der Blob hat für Bitcoin keine Bedeutung: Das Netzwerk unternimmt nichts zu seiner Verifikation und erzwingt keinerlei Regeln dagegen.

Infolgedessen ist es durchaus möglich, dass ungültige Shielded-Bitcoin-Transaktionen auf der Kette landen. Es obliegt einem Shielded-Bitcoin-Indexer, der die Blockchain passiv beobachtet, Transaktionen zu ignorieren, die die Validierung nicht bestehen, und sie bei der Aktualisierung des Zustands der Netzwerkguthaben nicht anzuwenden.

Nullifier statt eines ausgegebenen Sets

Ein Indexer löscht keine Notes aus einem Set unverbrauchter Notes, so wie Bitcoin ausgegebene UTXOs entfernt. Stattdessen führt er ein Nullifier-Set. Dieser Mechanismus ermöglicht es einem Nutzer, öffentlich einen verschlüsselten Beweis und einen Nullifier zu veröffentlichen, die zeigen, dass eine Note ausgegeben wurde, ohne preiszugeben, welche Note ausgegeben wurde. Statt zu prüfen, ob sich eine Note im „unverbrauchten Noten-Set“ befindet, prüfen die Teilnehmer, ob ein bestimmter Nullifier bereits verwendet wurde.

Indexer bauen einen Merkle-Baum, der für immer wächst und nur ergänzt werden kann und jede jemals erstellte Note-Ausgabe enthält, neben demifier-Set.

Der Betrieb des Protokolls erfordert nur einen Node

Die Nutzung des Protokolls erfordert nichts weiter als einen Bitcoin-Node und einen Shielded-Bitcoin-Indexer. Kein Dienst, kein Koordinator und kein Off-Chain-Zustand ist nötig, um Mittel wiederherzustellen. Es funktioniert wie On-Chain-Bitcoin: Alles, was ein Nutzer benötigt, sind sein Node/Indexer und seine Schlüssel.

Jede Nutzer-Wallet leitet einen geheimen Masterschlüssel ab, aus dem alle anderen beteiligten Schlüsselsätze erzeugt werden – ein Design, das einer HD-Wallet in Bitcoin stark ähnelt, aus der viele Adresssätze generiert werden können. sk_spend dient als privater Ausgabeschlüssel, sk_nf wird zum Nullifizieren von Note-Ausgaben verwendet, vk_in entschlüsselt und zeigt eingehende Notes an, vk_out zeigt ausgehende Transaktionen an, und sk_view generiert eine Empfangsadresse.

Wenn ein Nutzer jemandem eine Adresse für den Empfang von Mitteln geben möchte, generiert er einen Diversifier-Wert d, ähnlich einem Derivationswert, und multipliziert ihn mit seinem sk_view-Schlüssel. Der resultierende öffentliche Schlüssel pk_d bildet zusammen mit d die Adresse des Nutzers.

Der Sender generiert dann einen Zufallswert, den r_seed, der sowohl zur Verschlüsselung der Note-Ausgabe als auch zur Nullifizierung benötigt wird. Transaktionsausgaben enthalten nur drei verschlüsselte Elemente: den Wert der Ausgabe, den d-Wert, den der Empfänger dem Sender gegeben hat, und den r_seed-Wert des Senders. Zur Verschlüsselung verwendet der Sender ein geheimes ephemeres Schlüsselpaar und den öffentlichen Schlüssel des Empfängers, um ein geteiltes Geheimnis zu erzeugen – beide Parteien können dasselbe Geheimnis berechnen, indem sie ihren privaten Schlüssel mit dem öffentlichen Schlüssel der anderen Partei multiplizieren. Die Note-Ausgabe wird mit diesem geteilten Geheimnis verschlüsselt, und der ephemere sk_eph wird unverschlüsselt beigefügt, damit der Empfänger das geteilte Geheimnis selbst erzeugen kann.

Zero-Knowledge-Proofs garantieren Gültigkeit

Auf der Input-Seite sind zwei Dinge erforderlich, damit eine Transaktion gültig ist: ein öffentlicher Nullifier für jede konsumierte Note-Ausgabe und ein Zero-Knowledge-Proof, der belegt, dass (1) die Note-Ausgabe im Merkle-Baum der Notes enthalten ist, (2) die Transaktion durch den entsprechenden sk_spend-Schlüssel autorisiert ist, (3) der Nullifier korrekt abgeleitet ist und (4) keine Inflation stattgefunden hat.

Der Nullifier beinhaltet den sk_nf-Schlüssel, einen aus dem r_seed abgeleiteten ρ-Wert und die Position der Note im Merkle-Baum der Note-Ausgaben. Obwohl niemand erkennen kann, welcher Note-Ausgabe ein Nullifier entspricht, garantieren die Zero-Knowledge-Proofs in jeder Transaktion, dass jeder dem Set hinzugefügte Nullifier von einer gült Note-Ausgabe stammt. Indexer können daher wiederholte Nullifier einfach ablehnen, statt ausgegebene Notes zu löschen, und solange es keine Wiederholungen gibt, bietet das System dieselbe Garantie gegen Doppel-Ausgaben.

Der Nettoeffekt ist, dass verschlüsselte Metaprotokoll-Transaktionen in die Bitcoin-Blockchain eingebettet werden können und dennoch garantieren, dass nichts doppelt ausgegeben wird und keine Coins aus dem Nichts geschaffen werden.

Privacy-Eigenschaften

Laut der Analyse ist das System in Bezug auf die Privacy-Eigenschaften gut gestaltet und hält mit etwas wie Zcashs Shielded Pools Schritt. Der Vergleich zeichnet das größere Bild: Zcash liefert geschützte Transaktionen durch Regeln, die in sein eigenes Protokoll eingebaut sind, während dieses Design vergleichbare Eigenschaften auf der Bitcoin-Basisebene anstrebt, ohne den Konsens anzutasten. Privacy-Überlegungen, die beim Ein- und Ausstieg in das Metaprotokoll entstehen, sollen in einer kommenden Paper-Veröffentlichung detailliert werden; die Ein- und Ausstiegspunkte des Systems gehören damit zu den Details, die man im Auge behalten sollte. Anders als bei Coinjoins gibt es keine Sorge um die Messbarkeit der Privatsphäre oder die Notwendigkeit periodischen Remixens.

Pegging von Mitteln mit PIPEs v2

Der vorgesehene Peg stützt sich auf PIPEs v2, ein Witness-Encryption-Verfahren. PIPEs ermöglichen es, einen privaten Schlüssel mit einem Programm oder Mechanismus zu verschlüsseln, der den Schlüssel nicht preisgibt, es sei denn, es wird ein ZK-Proof vorgelegt, der zeigt, dass eine bestimmte Bedingung erfüllt ist – etwa der Zustand eines bestimmten UTXO oder die Bestätigung einer Transaktion. Dies würde einen Peg ohne Operator, Föderation oder jede dritte Partei, die Mittel verwahrt, funktionsfähig machen – eine bemerkenswerte Eigenschaft, da Peg-Designs, die Bitcoin erweitern, typischerweise auf solche Verwahrer gesetzt haben. Es erfordert keine Soft Forks oder Protokolländerungen an Bitcoin und findet vollständig off-chain statt.

Die nächste Phase der Arbeit des Teams ist ein Pegging-Mechanismus, der es Nutzern ermöglichen soll, Mittel über kryptografisch kontrollierte PIPEs-Schlüssel in Shielded Bitcoin einzuzahlen, die dann durch die Erzeugung eines ZK-Proofs legitimer, on-chain bestätigter Peg-out-Transaktionen „entriegelt“ werden. An dem Paper, das diesen Aspekt des Systems definiert, wird derzeit gearbeitet; es soll in naher Zukunft veröffentlicht werden und wird zusammen mit dem Paper zur Ein-/Ausstiegs-Privatsphäre die offenen Punkte des Whitepapers schließen.

---

Dieser Artikel, geschrieben von Shinobi, erschien zuerst auf Bitcoin Magazine.