Dieser Artikel befasst sich mit einem technologischen Konzept, das auf dem vorgeschlagenen Upgrade des Taproot-Protokolls basiert. Wenn Sie noch nicht mit den Grundlagen der Funktionsweise von Taproot vertraut sind, sollten Sie diese zuerst lesen dieser Erklärer.
PfahlwurzelEin potenzielles Upgrade des Bitcoin-Protokolls, das erstmals von Gregory Maxwell, einem Mitarbeiter von Bitcoin Core, vorgeschlagen wurde, befindet sich in einem späten Entwicklungsstadium. Die Technologie besteht aus einer cleveren Kombination von Krypto-Tricks, mit denen Benutzer komplexe intelligente Verträge in normal aussehenden Transaktionen verstecken können. Die Komplexität wird nur dann deutlich, wenn die Vertragsparteien nicht kooperativ sind.
Ausgehend von dieser Idee haben Bitcoin Core-Mitarbeiter, darunter (ohne darauf beschränkt zu sein) Jeremy Rubin, Antoine Riard, Gleb Naumenko und Gregory Maxwell selbst, über ein allgemeines Konzept spekuliert, das als bezeichnet wird Zahlungspools, Joinpools oder Münzpools. Mit diesen Pools - wir werden sie vorerst als Zahlungspools bezeichnen - können Benutzergruppen das Eigentum an denselben Münzen (technisch: UTXOs) teilen, die in der Bitcoin-Blockchain aufgezeichnet sind, während jeder dieser Benutzer Zahlungen ausführen (oder empfangen) kann mit ihnen. Da sich die Gruppe und ihre einzelnen Mitglieder in einer Taproot-Struktur „verstecken“, genießen alle mehr Privatsphäre, intelligente Vertragsflexibilität und andere Vorteile… und sie genießen diese Vorteile möglicherweise sogar außerhalb der Kette, wodurch Zahlungspools zu einer neuen Layer-Two-Lösung werden.
Obwohl die Designspezifikationen von einem Zahlungspoolvorschlag zum nächsten etwas variieren, ist das allgemeine Konzept dasselbe. Hier ist die Grundidee…
Eine Münze teilen
Um einen Zahlungspool zu erstellen, kombinieren Benutzer zunächst ihre (Bruchteile von) Münzen, indem sie sie in einer von ihnen gemeinsam genutzten Taproot-Adresse zusammenfassen. Nehmen wir also an, Alice besitzt drei Münzen, Bob besitzt zwei Münzen und Carol besitzt eine Münze für insgesamt sechs. Zusammen erstellen sie eine Transaktion, die diese Münzen an die gemeinsam genutzte Adresse sendet und so einen Zahlungspool mit sechs Münzen bildet.
In der Blockchain sieht die Zahlungspooladresse wie eine normale Bitcoin-Adresse aus, die jetzt sechs Münzen enthält. Aber unter der Oberfläche verwendeten Alice, Bob und Carol geschickt Taproot, um sicherzustellen, dass jeder von ihnen die Kontrolle über seinen eigenen Anteil an Münzen im Zahlungspool behält. Alice kann jederzeit drei Münzen von der Adresse beanspruchen, Bob kann jederzeit zwei und Carol eine.
Dies liegt daran, dass es nur zwei Hauptoptionen gibt, um Münzen von der Adresse auszugeben.
Die erste Möglichkeit besteht darin, den Taproot-Schlüsselpfad technisch direkt von der Adresse aus auszugeben. Dies erfordert die Zusammenarbeit (dh kryptografische Signaturen) aller drei Teilnehmer. Wenn Alice, Bob und Carol sich einig sind, können die sechs Münzen ausgegeben werden, wie sie möchten, und dies sieht aus wie jede andere reguläre Transaktion im Bitcoin-Netzwerk. Das Trio kann beispielsweise beschließen, die jeweiligen Guthaben an einzelne Adressen zurückzusenden: drei für Alice, zwei für Bob und eine für Carol. Aber wenn sie sich dafür entscheiden würden, könnten sie auch zusammenarbeiten, um alle sechs Münzen an Julian zu spenden, oder sie auf eine andere Weise ausgeben, auf die sie sich einigen könnten. Wichtig ist, dass alle drei teilnehmen müssen, damit niemandes Gleichgewicht ohne seine eigene Mitarbeit ausgegeben wird.
Die zweite Hauptoption besteht tatsächlich aus mehreren Unteroptionen. Bevor Alice, Bob und Carol ihre Münzen an den Zahlungspool schickten, versteckten sie etwas im kryptografischen Baum hinter der Taproot-Adresse: Sie enthielten alternative Möglichkeiten, um Geld aus dem Zahlungspool zu senden. (Derzeit könnte dies realisiert werden, indem alle drei Teilnehmer Transaktionen von diesen Pfaden vorsignieren, was eine gewisse Komplexität beim Einrichten aller Optionen erfordern würde und nicht sehr gut skalierbar ist. Vorgeschlagene Protokollaktualisierungen könnten dies möglicherweise in Zukunft einfacher machen .)
Wenn einer der Teilnehmer die Münzen im Zahlungspool über einen alternativen Taproot-Pfad ausgeben würde, würde er normalerweise einen Betrag, der dem Guthaben dieses Teilnehmers entspricht, an eine Adresse seiner Wahl senden, wie eine individuelle Adresse, die er kontrolliert. (In Alices Fall drei Münzen an ihre eigene Adresse, in Bobs Fall zwei an seine Adresse und in Carols Fall eine.)
Auf diesem alternativen Weg werden auch die verbleibenden Münzen automatisch ausgegeben. Dies kann je nach Gestaltung des Zahlungspools auf verschiedene Arten erfolgen und bietet unterschiedliche Kompromisse hinsichtlich Komplexität und Skalierbarkeit.
Die einfachste Lösung besteht darin, jedem anderen Teilnehmer seinen Anteil an Münzen an eine Adresse seiner Wahl zu senden. Mit anderen Worten: Wenn ein Benutzer den Pool verlässt, verlässt jeder den Pool.
Eine zweite Lösung, die von Riard und Naumenko bevorzugt wird, besteht darin, alle verbleibenden Münzen an a zu senden neu Der Zahlungspool, der genau wie der erste Zahlungspool aussieht, wurde nur von allem befreit, was den jetzt verlassenen Benutzer betraf. Dieses Design bietet die beste Benutzererfahrung, ist jedoch am schwierigsten zu skalieren, vor allem, weil alle möglichen Exit-Szenarien vorbereitet werden müssen, einschließlich aller möglichen Exit-Szenarien für alle potenziellen neuen Pools. Die Skalierung könnte jedoch mit einem noch zu benennenden potenziellen Bitcoin-Protokoll-Upgrade erreicht werden, um sicherzustellen, dass die Regeln aus dem vorherigen Zahlungspool auf einen neuen Zahlungspool übertragen werden.
Rubin hält diese zweite Lösung jedoch für unpraktisch und zieht es vor, etwas zwischen der ersten und der zweiten Lösung zu wählen: Einige Teilnehmer erhalten ihre Münzen sofort an eine Adresse ihrer Wahl, andere Teilnehmer lassen ihre Münzen an einen neuen Zahlungspool senden. Dieses Design bietet eine weniger ideale Benutzererfahrung, würde jedoch besser skalieren, und das potenzielle Upgrade des OP_CHECKTEMPLATEVERIFY-Protokolls würde dazu beitragen, das Design zu vereinfachen und die Skalierung noch weiter zu erhöhen. (Exits würden über Tree Payments erfolgen. Diese Arten von Zahlungen werden in weiter unten untersucht Dieser Artikel.)
(Es gibt mehr Kompromisse zwischen der zweiten und dritten Lösung, aber die Details aller Vor- und Nachteile liegen außerhalb des Geltungsbereichs dieses Artikels Diskussion der Bitcoin-Entwickler-Mailingliste für Einzelheiten.)
Um zu sehen, was es bedeutet, wenn verbleibende Münzen an einen neuen Zahlungspool gesendet werden, wählen Alice, Bob und Carol die zweite Option, wo alle Die restlichen Münzen werden an einen neuen Zahlungspool gesendet. Wenn Alice in diesem Design den ersten Zahlungspool verlässt, werden drei Münzen an eine Adresse ihrer Wahl gesendet, während die anderen drei Münzen an einen neuen Zahlungspool zwischen Bob und Carol gesendet werden. Zu diesem Zeitpunkt hat Alice wieder die alleinige Kontrolle über ihre eigenen Münzen, während sich für Bob und Carol nicht viel geändert hat. Die beiden können immer noch zusammenarbeiten, um die drei verbleibenden Münzen auszugeben, wie sie möchten, oder eine von ihnen kann einseitig aussteigen, wie Alice es zuvor getan hatte.
Wenn Bob dann einseitig aus dem zweiten Zahlungspool austritt, sendet er zwei Münzen an eine Adresse seiner Wahl und eine Münze an einen noch neueren Zahlungspool (den dritten), wobei nur noch Carol übrig ist. (Natürlich wäre in diesem vereinfachten Beispiel ein Entwurf, bei dem dieser letzte Zahlungspool durch eine Adresse von Carol ersetzt wird, in Wirklichkeit sinnvoller, aber das ist ein Implementierungsdetail.)
Der wichtige Aspekt ist, dass Teilnehmer eines Zahlungspools zusammenarbeiten können, um jede Art von Zahlung aus dem gewünschten Pool zu leisten, während jeder von ihnen jederzeit mit seinen eigenen Münzen aussteigen kann, sodass andere Teilnehmer die Kontrolle über ihre haben.
Einzahlung in den Zahlungspool
Wir haben also festgestellt, dass alle Teilnehmer ihr Guthaben einzeln aus einem Zahlungspool abheben oder - wenn sie alle einverstanden sind - aus dem Pool ausgeben können. Es ist diese zweite Option, die tatsächlich etwas Kluges ermöglicht: Der Zahlungspool kann dynamisch sein. Solange alle Teilnehmer einverstanden sind, können sie nicht nur ihr Geld zurückzahlen oder andere (wie Julian) bezahlen, sondern auch etwas noch Interessanteres tun. Sie können ihr Geld in neuere Versionen des Zahlungspools mit unterschiedlichen Designs verschieben.
So kann beispielsweise einer von ihnen aus dem Pool ausgeben.
Nehmen wir an, Alice kauft ein neues Auto und möchte es mit einem Bitcoin bezahlen. Alice, Bob und Carol könnten dann eine Transaktion aus dem Zahlungspool erstellen, die eine Münze an das Autohaus sendet und die verbleibenden fünf Münzen an a sendet neu Zahlungspool, der genauso aussieht wie der erste, außer dass Alice diesmal nur einseitig mit zwei Münzen aus dem Pool aussteigen kann, eine weniger als zuvor.
Die Transaktion sah unterdessen wie jede andere reguläre Bitcoin-Transaktion aus. Das Autohaus (oder Blockchain-Spione) könnte zu dem Schluss kommen, dass Alice alle sechs Münzen besaß und einfach eine zum Kauf des Autos verwendete und die anderen fünf als Wechselgeld behielt. Sie hätten keine Ahnung, dass einige der Münzen Bob und Carol gehören oder dass sie überhaupt an der Transaktion beteiligt waren.
Wenn Bob das nächste Mal eine Zahlung leistet und Alice und Carol zusammenarbeiten, erfolgt dies aus demselben Zahlungspool, der für die Außenwelt wieder wie eine gewöhnliche Bitcoin-Transaktion aussieht. In der resultierenden Iteration des Zahlungspools kann Bob mit einer Münze anstelle von zwei Münzen aussteigen. In der Zwischenzeit haben dieselben Blockchain-Spione möglicherweise gedacht, Alice würde erneut eine Zahlung leisten, was sie weiter verwirrt. (Und selbst wenn die Blockchain-Spione irgendwie herausfinden würden, dass die Adresse wirklich ein Zahlungspool zwischen Alice, Bob und Carol ist, konnten sie immer noch nicht sagen, welcher der drei die letzte Zahlung geleistet hat.)
Jedes Mal, wenn Alice, Bob oder Carol Münzen ausgeben, kann die Transaktion von einem von ihnen stammen, und niemand außerhalb des Zahlungspools kann den Unterschied feststellen.
Zahlungspools ermöglichen nicht nur Ausgaben. Wenn Alice ihr „Guthaben“ im Zahlungspool aufladen möchte, könnte sie dies auch tun. Alice, Bob und Carol würden in diesem Fall zusammenarbeiten, um die aktuellen fünf Münzen an eine neue Taproot-Adresse zu verschieben, an die Alice in derselben Transaktion eine zusätzliche Münze von einer ihrer eigenen (individuellen) Adressen senden würde. Die neue Taproot-Adresse würde wieder sechs Münzen enthalten, von denen drei Alice gehören, was sich in ihrer einseitigen Ausstiegsoption widerspiegelt.
Auf die gleiche Weise könnten auch völlig neue Benutzer dem Zahlungspool beitreten. Wenn Alice, Bob und Carol zustimmen, Dave teilnehmen zu lassen, arbeiten die drei mit Dave zusammen, um eine Transaktion zu erstellen, die das Geld des Zahlungspools zusammen mit Daves neuen Münzen an einen neuen Zahlungspool sendet, damit Dave auch teilnehmen und aussteigen kann wenn er so wählen würde.
Darüber hinaus haben Teilnehmer innerhalb des Zahlungspools die Möglichkeit, sich gegenseitig zu bezahlen. Wenn Alice zum Beispiel Bob eine Münze bezahlen würde, könnten die drei zusammenarbeiten, um das Geld an einen neuen Zahlungspool zu senden, in dem Alice eine Münze von ihrem Guthaben abziehen lässt und Bob eine Münze hinzufügt. Auch in der Blockchain würde es wie eine reguläre Zahlung aussehen, und Blockchain-Spione hätten keine Ahnung, wer wen oder wie viel bezahlt hat. (Es ist erwähnenswert, dass Dave auf ähnliche Weise in den Pool hätte gelangen können, indem er eine interne Zahlung von einem der vorhandenen Teilnehmer erhalten hat.)
Mit ein bisschen mehr Komplexität (und idealerweise mit mindestens einem zusätzlichen Bitcoin-Protokoll-Upgrade wie Keine Eingabe) könnten Transfers auch außerhalb der Kette durchgeführt werden. Wenn Alice Bob bezahlt, würden alle Teilnehmer in diesem Fall eine Transaktion erstellen, die Geld für einen neuen Zahlungspool ausgibt, aber diese Transaktion würde nur zwischen ihnen geteilt - nicht an das Netzwerk gesendet (es sei denn, jemand versucht jemals zu betrügen). Auf diese Weise konnten Alice, Bob und Carol ihr Guthaben „intern“ weiter aktualisieren und Dave sogar irgendwann in den Pool lassen. Wenn alle einverstanden sind, den Pool zu schließen, können sie eine endgültige Transaktion erstellen, die aus dem ursprünglichen Zahlungspool ausgegeben wird, und jedem ihren letzten Saldo zuweisen.
Ähnlich einer älteren Idee bekannt als KanalfabrikenDiese Arten von Zahlungspools könnten schließlich sogar dazu verwendet werden, Lightning-Kanäle, Tresore oder andere Layer-Two-Protokolle selbst zu hosten. Dies kann das Potenzial bieten, jede Art von zusätzlicher Protokollschicht in solche Pools zu "wickeln", wodurch ihre gesamte Komplexität in identischen und regelmäßig aussehenden Transaktionen verborgen wird.