PIECHAIN-Demo: Erkundung eines praktischen Blockchain-Interoperabilitätsrahmens

Autoren: (1) Daniel Reijsbergen, Nanyang Technological University, Singapore, Singapur; (2) Aung Maw, Singapore University of Technology and Design, Singapur, Singapur; (3) Jingchi Zhang, Nanyang Technological University, Singapore, Singapur; (4) Tien Tuan Anh Dinh, Deakin University, Melbourne, Australien; (5) Anwitaman Datta, Nanyang Technological University, Singapur, Singapur. Inhaltsübersicht Zusammenfassung & Einleitung Übersicht über PIEChain Implementierung von PIEChain Demonstrationsplan Erweiterungen Verweise Abstrakt In den letzten Jahren ist eine Vielzahl verschiedener Blockchain-Plattformen entstanden, aber viele von ihnen arbeiten isoliert. Daher ist eine zuverlässige kettenübergreifende Kommunikation erforderlich, um die Interoperabilität der Blockchain zu ermöglichen. Die Interoperabilität der Blockchain ist eine Herausforderung, da Transaktionen normalerweise nicht rückgängig gemacht werden können. Wenn also eine Transaktion festgeschrieben wird, muss das Protokoll sicherstellen, dass auch alle zugehörigen Transaktionen festgeschrieben werden. Bestehende Interoperabilitätsansätze, z. B. Cosmos und Polkadot, sind insofern begrenzt, als sie nur die Interoperabilität zwischen ihren eigenen Subchains unterstützen oder aufdringliche Änderungen an vorhandenen Blockchains erfordern. Um diese Einschränkung zu überwinden, schlagen wir PIECHAIN vor, ein allgemeines, Kafka-basiertes kettenübergreifendes Kommunikationsframework. Wir verwenden PIECHAIN für eine praktische Fallstudie: eine kettenübergreifende Auktion, bei der Benutzer, die Token auf mehreren Chains halten, auf ein Ticket bieten, das auf einer anderen Chain verkauft wird. PIECHAIN ist die erste öffentlich verfügbare, praktische Implementierung eines allgemeinen Frameworks für kettenübergreifende Kommunikation. I. EINLEITUNG Eine Blockchain ist eine replizierte, manipulationssichere Datenbank, die für feindliche Umgebungen entwickelt wurde. Sie besteht aus einer Reihe von Knoten, von denen einige bösartig sein können, die ein Ledger verwalten, das nur Anhänge enthält. Das Ledger speichert Transaktionen, die einige globale Zustände ändern. Im kanonischen Beispiel, also bei Kryptowährungen [7], sind die globalen Zustände Benutzerkonten und native (fungible) Token, und das Ledger enthält Transaktionen, mit denen Token von einem Konto auf ein anderes übertragen werden. In einer anderen aufkommenden Anwendung speichern die Blockchains nicht fungible Token (NFTs), die Vermögenswerte eindeutig repräsentieren, z. B. digitale Kunstwerke oder Konzertkarten. Viele Blockchains unterstützen auch Smart Contracts, mit denen Benutzer ihre eigenen Zustände und Codes definieren können, die die Zustände ändern. Smart Contracts werden im Ledger gespeichert und von allen Blockchain-Knoten repliziert und konsistent gehalten. In den letzten Jahren sind viele unabhängige Blockchain-Plattformen entstanden, was zu einem Ökosystem mit einem langen Schwanz geführt hat. Einerseits gibt es eine kleine Anzahl äußerst beliebter, universeller Blockchain-Plattformen wie Ethereum und Hyperledger. Auf der anderen Seite gibt es Tausende kleinerer Blockchains, die für bestimmte Anwendungen entwickelt wurden und sich größtenteils noch in einem frühen Entwicklungsstadium befinden. Dazu gehören Anfang 2023 mehr als 10.000 Kryptowährungen [3] sowie Blockchains für das Gesundheitswesen, das Identitätsmanagement und das IoT. Im Allgemeinen sind diese Blockchains nicht interoperabel, d. h. sie existieren in Silos. Daher ist die Blockchain-Interoperabilität, d. h. die Fähigkeit der Benutzer, Informationen oder Vermögenswerte auf verschiedenen Blockchains auszutauschen, ein Thema, das in der Forschungsgemeinschaft zunehmend auf Interesse stößt [6], [10], [4], [1], [11]. Eine der größten Herausforderungen bei der Entwicklung eines sicheren Blockchain-Interoperabilitätsrahmens besteht darin, die Atomizität zu garantieren, d. h. dass entweder alle Schritte eines vereinbarten Satzes von Transaktionen erfolgreich beendet werden oder keiner. Dies ist bei Blockchains komplizierter als bei herkömmlichen Datenbanken, da Blockchain-Transaktionen (im Prinzip) irreversibel sind. Wenn beispielsweise eine Zahlung für ein NFT auf Kette A bereits auf Kette B erfolgt ist, erfordert die Atomizität, dass die Transaktion auf Kette A fortgesetzt werden muss, da die Transaktion auf Kette B nicht rückgängig gemacht werden kann. Ein gängiger Ansatz zur Gewährleistung der Atomizität besteht darin, alle an der Transaktion beteiligten Token in Smart Contracts treuhänderisch zu verwahren und sie nur durch eine von allen Parteien unterzeichnete Commit-Nachricht freizugeben [6]. Eine weitere wichtige Herausforderung bei der Blockchain-Interoperabilität besteht darin, die Lebendigkeit zu garantieren, sodass die treuhänderisch verwahrten Token nicht für immer eingefroren werden können. Um die Lebendigkeit sicherzustellen, muss es für Knoten möglich sein, eine Abbruchnachricht zu senden, die es allen Parteien ermöglicht, ihre Vermögenswerte aus der Treuhand zu ziehen. Um sowohl Atomizität als auch Lebendigkeit zu gewährleisten, muss ein Interoperabilitätsrahmen in der Lage sein, gegnerische Knoten zu tolerieren, die eine Commit-Nachricht an eine Blockchain und eine Abbruch-Nachricht an eine andere senden. Es ist bekannt, dass dies bei asynchronen Netzwerken (d. h. bei denen es keine Begrenzung der Nachrichtenverzögerungen gibt) ohne eine vertrauenswürdige dritte Partei (TTP) unmöglich ist [10]. Es gibt zwei Hauptansätze, um diese Herausforderung zu bewältigen [6]. Der erste Ansatz besteht darin, eine Synchronitätsannahme mit einer Abkühlungsphase für Abbrüche zu kombinieren – d. h. anzunehmen, dass eine einmal generierte Commit-Abstimmung an alle betroffenen Blockchains angehängt werden kann, bevor eine Abkühlungsphase für Abbrüche endet. Dieser Ansatz wird z. B. bei gehashten zeitgesperrten Verträgen verfolgt [5]. Der zweite Ansatz besteht darin, die TTP durch eine andere Blockchain zu ersetzen, um sicherzustellen, dass entweder eine gültige Commit- oder Abbruch-Nachricht erstellt werden kann, aber nicht beides [6], [9]. Obwohl Ansätze beider Typen in der wissenschaftlichen Literatur vorgeschlagen wurden, verfügen sie entweder nicht über eine öffentlich verfügbare Implementierung [5], [6], [9] oder sind in ihrem Anwendungsbereich begrenzt, z. B. beim Erstellen von gesicherten Vermögenswerten auf einer anderen Blockchain [11] oder beim Token-Swapping [8]. In einer separaten Entwicklung sind mehrere Blockchain-Plattformen entstanden, die standardmäßig Interoperabilität ermöglichen, z. B. Cosmos und Polkadot. Diese Plattformen unterstützen jedoch nur die Interoperabilität zwischen ihren eigenen Subchains oder erfordern intrusive Änderungen an bestehenden Blockchains. Dies motiviert die Notwendigkeit eines allgemeinen und praktischen Interoperabilitätsrahmens, der mit bestehenden Blockchain-Plattformen verbunden werden kann, ohne diese zu modifizieren. Unser Ziel ist es, einen solchen Rahmen bereitzustellen. : Um dieses Ziel zu erreichen, präsentieren wir PIECHAIN. Da Synchronität in der Praxis schwer anzunehmen ist, verwendet PIECHAIN Cross-Chain-Dienste, um das TTP zu ersetzen. Die Cross-Chain-Dienste kommunizieren über ein Ereignisprotokoll, das aus Effizienzgründen das Kafka-Protokoll von Apache verwendet. Um die praktische Relevanz von PIECHAIN zu demonstrieren, haben wir einen Cross-Chain-Dienst für eine realistische Fallstudie implementiert: eine Cross-Chain-Auktion. Wir haben PIECHAIN mit einigen der beliebtesten Blockchain-Plattformen verbunden, die Smart Contracts unterstützen: Ethereum, Hyperledger Fabric und Quorum. Schließlich haben wir eine GUI für unsere Fallstudie entwickelt. Die Auktionsfallstudie ist eine von drei Fallstudien (zwei Auktionen und ein Blitzkredit [6]), deren Code im PIEChain-Code-Repository auf GitHub zu finden ist. Beiträge & Neuheit II. ÜBERBLICK ÜBER PIECHAIN A. Entitäten Die Hauptentitäten in PIECHAIN sind wie folgt (siehe auch Abbildung 1): Blockchains, die von Benutzern gehaltene Vermögenswerte (z. B. Token, Schlüssel) speichern. Ein Benutzer kann Vermögenswerte auf mehreren Blockchains halten. Jede Blockchain hat ihr eigenes Protokoll, um zu bestimmen, wer Lese- und Schreibzugriff hat – Blockchains sind normalerweise entweder berechtigungsbehaftet, d. h. ein fester Satz von Knoten hat Lese- und Schreibzugriff, oder berechtigungsfrei, d. h. jeder hat Lesezugriff und kann Transaktionen erstellen, und Knoten mit ausreichender Leistung (z. B. Verarbeitungsgeschwindigkeit) können Transaktionen zur Blockchain hinzufügen. Cross-Chain-Dienste (CC-SVCs), die es Benutzern ermöglichen, Vermögenswerte auf verschiedenen Blockchains auszutauschen. Jeder CC-SVC besteht aus einem Server, der mit Benutzerclients interagiert, um die kettenübergreifende Kommunikation zu erleichtern. In der Praxis berechnet der CC-SVC den Benutzern die Teilnahme und kann mit einer beliebigen Anzahl von Blockchains interagieren. Im Folgenden entspricht jeder CC-SVC einer Reihe von Ereignissen, die an einem atomaren Austausch von Vermögenswerten beteiligt sind, die von einem Server an das Kafka-Ledger gesendet werden. In der Praxis kann ein einzelner Server viele CC-SVCs betreiben. Das Kafka-Netzwerk, das als Nur-Anhänge-Protokoll der von den CC-SVCs generierten Ereignisse dient. Ereignisse entsprechen Transaktionen, die auf zugrunde liegenden Blockchains durchgeführt werden. Das Kafka-Netzwerk wird von einer festen Gruppe von Knoten betrieben, die CCSVCs für das Hochladen von Ereignissen Gebühren berechnen. In PIECHAIN gehen wir davon aus, dass die CC-SVCs halb vertrauenswürdig sind und dass sie motiviert sind, sich ehrlich zu verhalten, da sie einen Ruf zu wahren haben, ähnlich wie kommerzielle ausgelagerte Dienstleister. Die Betreiber des Kafka-Netzwerks sind nicht vertrauenswürdig, haben aber keinen Anreiz, sich schlecht zu verhalten, da sie nicht mit den zugrunde liegenden Blockchains interagieren. Dies ermöglicht es uns, ein Protokoll (Kafka) auszuführen, das Effizienz vor Sicherheit priorisiert. Ein alternativer Entwurf besteht darin, die CC-SVCs nicht vertrauenswürdig und das Kafka-Netzwerk vertrauenswürdig zu machen. In diesem Fall führt jeder Kafka-Knoten einen (leichten) Client für jede der zugrunde liegenden Blockchains aus, um die Einbeziehung von Transaktionen in diese Ketten zu validieren. In diesem Fall müsste das Ereignisprotokoll ein sichereres Protokoll wie PBFT [2] verwenden. Wir überlassen einen solchen Entwurf der zukünftigen Arbeit. B. Prozessablauf Unter Berücksichtigung der Entitäten aus Abschnitt II-A hat der Prozessablauf in PIECHAIN die gleiche Struktur wie Cross-Chain-Deals, wie sie von Herlihy et al. [6] vorgeschlagen wurden. Cross-Chain-Deals sind Vereinbarungen mehrerer Benutzer zum Austausch von Vermögenswerten auf verschiedenen Blockchains und bestehen aus fünf Phasen (siehe auch Abbildung 2): Clearing-Phase: Das CC-SVC erstellt die Smart Contracts auf den verschiedenen Blockchains, die für die Treuhandverwaltung und Übertragung der im Geschäft enthaltenen Vermögenswerte verwendet werden. Treuhandphase: Die Benutzer hinterlegen ihre ausgehenden Vermögenswerte treuhänderisch, indem sie sie auf die Smart Contracts übertragen. Übertragungsphase: Die Vermögenswerte werden vorläufig ausgetauscht, d. h. die Ausführungslogik der Smart Contracts wird festgelegt. Validierungsphase: Jeder Benutzer prüft, ob das Ergebnis der Ausführungslogik zu seiner Zufriedenheit ist. Commit-Phase: Der Deal wird durch Commitment abgeschlossen, wenn alle Parteien zufrieden sind, andernfalls durch Abbruch. Commitment bedeutet, dass die Ausführungslogik in den Smart Contracts ausgeführt wird und die Vermögenswerte wie im Deal angegeben ausgetauscht werden. Abbruch bedeutet, dass die Vermögenswerte in jedem Smart Contract an ihre ursprünglichen Eigentümer zurückgegeben werden. Zum Commit erstellen die Benutzer interaktiv eine Commit-Abstimmung, die vom CC-SVC an das Kafka-Ledger gesendet wird. Zum Abbrechen sendet ein einzelner Benutzer eine Abbruchnachricht an den CC-SVC. Für jeden CC-SVC kann dem Kafka-Ledger entweder eine Commit- oder eine Abbruchnachricht hinzugefügt werden, aber nicht beides. Ein Einschlussnachweis einer Commit-Abstimmung im Kafka-Ledger wird von allen Smart Contracts auf den verschiedenen Blockchains akzeptiert – dies garantiert, dass nach der Erstellung einer Commit-Abstimmung entweder alle Asset-Transfers ausgeführt werden können oder keine. III. UMSETZUNG VON PIECHAIN Um die praktische Anwendbarkeit von PIECHAIN zu veranschaulichen, haben wir es mit mehreren häufig verwendeten Blockchain-Plattformen verbunden und es verwendet, um eine Anwendung aus der wissenschaftlichen Literatur [6] zu implementieren: eine Cross-Chain-Auktion für einen digitalen Vermögenswert. Die Blockchain-Unterstützung erstreckt sich auch auf andere Fallstudien, wie wir in Abschnitt V diskutieren. A. Blockchain-Unterstützung Um eine zugrunde liegende Blockchain mit PIECHAIN zu verbinden, müssen die CC-SVCs in der Lage sein, Transaktionen auf diesen Ketten zu validieren. Unsere Implementierung unterstützt die folgenden Blockchain-Plattformen: Ethereum (sowohl die Proof-of-Work- als auch die Proof-of-Authority-Versionen des privaten Ethereum), Hyperledger Fabric und Quorum. Die beiden letzteren unterstützen genehmigungspflichtige Blockchains, während Ethereum eine genehmigungsfreie Hauptkette hat, aber auch private Ketten mit derselben Funktionalität unterstützt. B. Auktion In unserer Fallstudie verkauft ein Auktionator einen Vermögenswert auf einer Blockchain und erhält die Zahlung in Form von Vermögenswerten auf einer anderen Blockchain. Wie in [6] verwenden wir das Beispiel eines Ticketverkäufers. Das Ticket ist ein NFT auf einer dedizierten Blockchain, während die andere Blockchain häufiger verwendete fungible Token (z. B. Ether) unterstützt. Die erstere Blockchain wird als Ticket-Blockchain und die letztere als Coin-Blockchain bezeichnet. Dies lässt sich leicht auf Einstellungen mit mehr als einer Coin-Blockchain verallgemeinern. Im Folgenden betrachten wir eine First-Price-Auktion (d. h. der Bieter mit dem höchsten Gebot zahlt sein Gebot und erhält den Vermögenswert). Die fünf Phasen des Protokolls sind dann wie folgt: Der Auktionator beauftragt einen CC-SVC, der Smart Contracts auf der Ticket-Blockchain und den Coin-Blockchains erstellt. Der Auktionator überträgt seinen Vermögenswert (das NFT des Tickets) auf den Ticketvertrag, und die Bieter übertragen ihre Gebote auf den Vertrag in ihrer Coin-Blockchain. Die Ausführungslogik wird festgelegt: Der Auktionator aktualisiert jeden der Ticket- und Münzverträge, indem er angibt, welche Partei das Ticket erhält und welches Gebot an den Auktionator übermittelt wird. (Beachten Sie, dass diese Logik nicht a priori im Ticketvertrag angegeben werden kann, da der Vertrag auf der Ticketkette keine Daten aus den Münzblockchains lesen kann.) Jeder Benutzer (also Auktionator und Bieter) bestimmt, ob das Ergebnis des Übertragungsprotokolls für ihn akzeptabel ist, das heißt, ob das Ticket tatsächlich an den richtigen Empfänger übertragen wurde. Alle Benutzer erstellen eine Commit-Abstimmung. Sobald diese erstellt wurde, wird sie an jeden Vertrag gesendet, um die in der Übertragungsphase angegebenen Übertragungen durchzuführen. In PIECHAIN erfordert die Auktion zwei (logische) Arten von CC-SVC: den Relayer und den Signer. Der Relayer wartet auf Ereignisse (Gebote) in den Münzketten und leitet sie an die Ticket-Blockchain weiter. Der Signer hilft bei der Erstellung der Commit-Abstimmung. IV. DEMONSTRATIONSPLAN Für unsere Demonstration haben wir mithilfe des React-Frameworks eine grafische Benutzeroberfläche (GUI) entwickelt, um eine kettenübergreifende Auktion zu veranschaulichen. Die GUI besteht aus drei Hauptseiten: einer Dashboard-Seite, die eine Liste bekannter Auktionen anzeigt, wie in Abbildung 3 dargestellt, einer Detailansicht für einzelne Auktionen, wie in Abbildung 5 dargestellt, und einer Seite zum Erstellen neuer Auktionen (nicht angezeigt). Die Ansicht ist für einen Auktionator und für Bieter dieselbe. In der Dashboard-Ansicht können potenzielle Auktionatoren auf die Schaltfläche „Neue Auktion erstellen“ klicken, um eine Auktion zu starten – der Auktionator wählt einen CC-SVC, den zu versteigernden Vermögenswert, von welchen anderen Blockchains Gebote angenommen werden sollen, den Wechselkurs für Token zwischen verschiedenen Blockchains (der im Voraus festgelegt werden muss) und den Zeitpunkt, zu dem die Auktion abgeschlossen wird. Als Nächstes erstellt der Relay-CC-SVC die entsprechenden Verträge und sendet die Adresse des Vertrags in der Vermögenswertkette an den Auktionator. Der Auktionator kann die Auktion dann zu seinem Dashboard hinzufügen, indem er die Vertragsadresse hinzufügt und auf die Schaltfläche „Vorhandene Auktion hinzufügen“ klickt. Gleichzeitig gibt es die Vertragsadresse an potenzielle Bieter bekannt. Wenn die Bieter die Adresse des Asset-Vertrags erfahren, können sie diese auch zu ihren Dashboards hinzufügen. Nachdem der Bieter die Auktion hinzugefügt hat, kann er sie detaillierter anzeigen, indem er im Bedienfeld der Auktion auf die Schaltfläche „Anzeigen“ klickt, die ihn zur Detailansichtsseite führt. Auf dieser Seite kann der Bieter wichtige Informationen zur Auktion anzeigen, z. B. den Zeitpunkt ihrer Erstellung und ihres Abschlusses sowie eine Liste der Gebote. Das höchste Gebot ist mit einem Sternchen gekennzeichnet. Wenn die Auktion noch läuft, kann der Bieter ein Gebot hinzufügen, indem er die Blockchain angibt auf die das Gebot abgegeben wird und die Anzahl der zu bietenden Token. Anschließend wird eine Transaktion an den entsprechenden Münzvertrag durchgeführt und die Informationen werden an das Relais CC-SVC gesendet. Ein Benutzer kann alle Gebote, die er über das CC-SVC abgegeben hat, auch abbrechen. Nach Abschluss der Auktion informiert das Relay CC-SVC alle Teilnehmer und spezifiziert den vorläufigen Warentransfer in den Smart Contracts. Anschließend fordert das CC-SVC alle Clients der Teilnehmer auf, an der Erstellung eines Commit-Votings teilzunehmen. (Eine Nichtteilnahme sollte zu einer Strafe führen [4].) Wenn das Commit-Voting erstellt wurde, wird es an alle Verträge gesendet, um den endgültigen Vermögenstransfer einzuleiten. An diesem Punkt zeigt die GUI an, dass die Auktion abgeschlossen ist. Der genaue Ablauf der Demo wird wie folgt sein: Ein Benutzer – der Auktionator – öffnet eine webbrowserbasierte GUI und startet damit eine Auktion für einen ausgewählten Vermögenswert. Dabei werden alle Funktionen der Auktionserstellungsseite demonstriert. Der Vermögenswert existiert auf einer dedizierten Ticketkette, die in Hyperledger Fabric ausgeführt wird. Verträge werden auf allen beteiligten Blockchains erstellt (Schritt 1 von Abbildung 2). Mindestens zwei weitere Benutzer, die Browserfenster auf unterschiedlichen Rechnern verwenden, navigieren zur Detailseite der neu erstellten Auktion und geben ihre individuellen Gebote für den Vermögenswert ab (Schritt 2 von Abbildung 2). Mindestens ein Bieter verwendet (privates) Ethereum und der andere Quorum. Nach einiger Zeit ist die Auktion beendet und das Gewinnergebot ermittelt (Schritt 3 von Abbildung 2). Dies führt dazu, dass der Auktionator ein „Auktion beenden“-Ereignis an den Relay-CCSVC sendet. Die Unterzeichner, die auf diese Art von Ereignis warten, bemerken das Ereignis und erstellen eine Commit-Abstimmung (Schritt 4 von Abbildung 2). Die Commit-Abstimmung wird dann an Kafka gesendet und vom Relay-Knoten an den Auktionsvertrag und die Coin-Chain-Verträge weitergeleitet. An diesem Punkt wird der Vermögenswert an den Gewinner und das Gewinnergebot an den Auktionator übertragen (Schritt 5 von Abbildung 2). Während der gesamten Demo verwenden wir ein Terminalfenster, um nach jedem Schritt die Zustände der zugrunde liegenden Blockchains abzufragen, wie in Abbildung 4 dargestellt. Dadurch kann das Publikum die im Hintergrund stattfindenden Änderungen beobachten und mit dem Ablauf der Demonstration interagieren, z. B. indem es neue Aktionen anfordert, um zu sehen, wie sich die Hintergrundzustände ändern. Um den Ablauf der Demo zu veranschaulichen, finden Sie online ein Video 2, das die vorläufigen Demo-Folien und den Bildschirm zeigt, wenn Auktionator und Bieter ihre Aktionen an einem einzigen Computer ausführen würden. (Dies ist keine Einschränkung von PIECHAIN, erleichtert aber die Videoaufzeichnung.) V. ERWEITERUNGEN Das CC-SVC-Framework und die Schnittstelle für die unterstützten Blockchains können verwendet werden, um PIECHAIN problemlos auf andere Anwendungsfälle auszuweiten. Einer davon ist ein kettenübergreifender Flash-Kredit, wie in [6] beschrieben. Eine GUI für Flash-Kredite hätte nur begrenzte praktische Relevanz, da Arbitragemöglichkeiten typischerweise schnell gelöst werden, sodass die Interaktionen mit dem CC-SVC normalerweise von Trading-Bots durchgeführt würden. Wenn es die Zeit erlaubt, werden wir jedoch eine Visualisierung der Auswirkungen der Schritte in einem Flash-Kredit auf die Zustände der verschiedenen beteiligten Verträge anzeigen. VERWEISE [1] Rafael Belchior, Andre Vasconcelos, S ´ ergio Guerreiro und Miguel ´ Correia. Eine Umfrage zur Blockchain-Interoperabilität: Vergangene, gegenwärtige und zukünftige Trends. ACM Computing Surveys (CSUR), 2021. [2] Miguel Castro und Barbara Liskov. Praktische byzantinische Fehlertoleranz. In OsDI, Band 99, Seiten 173–186, 1999. [3] CoinLore. https://www.coinlore.com/all coins, 2023. [4] Daniel Engel, Maurice Herlihy und Yingjie Xue. Scheitern ist (buchstäblich) eine Option: Atomisches Engagement vs. Optionalität im dezentralen Finanzwesen. In SSS 2021, 2021. [5] Maurice Herlihy. In ACM PODC, Seiten 245–254, 2018. [6] Maurice Herlihy, Barbara Liskov und Liuba Shrira. Cross-Chain-Deals und kontroverser Handel. The VLDB Journal, 2021. [7] Satoshi Nakamoto. Bitcoin: Ein Peer-to-Peer-System für elektronisches Bargeld, 2008. [8] Sri AravindaKrishnan Thyagarajan, Giulio Malavolta und Pedro Moreno-Sanchez. Universal Atomic Swaps: Sicherer Austausch von Coins über alle Blockchains hinweg. In IEEE S&P, 2022. [9] Victor Zakhary, Divyakant Agrawal und Amr El Abbadi. Atomic Commitment über Blockchains hinweg. Proceedings of the VLDB Endowment, 13(9), 2021. [10] Alexei Zamyatin, Mustafa Al-Bassam, Dionysis Zindros, Eleftherios Kokoris-Kogias, Pedro Moreno-Sanchez, Aggelos Kiayias und William J Knottenbelt. SoK: Kommunikation über verteilte Ledger. In Financial Crypto, 2021. [11] Alexei Zamyatin, Dominik Harz, Joshua Lind, Panayiotis Panayiotou, Arthur Gervais und William Knottenbelt. Xclaim: Vertrauenslose, interoperable, durch Kryptowährungen gestützte Vermögenswerte. In IEEE S&P, 2019. Dieses Dokument ist . auf Arxiv unter der CC 4.0-Lizenz verfügbar