Kettenübergreifend erklärt: Lösungsbesprechung – DINNGO

In Technical Challenge haben wir eine leichte Implementierung für den Cross-Chain-Handel beschrieben. Durch den HTLC-basierten atomaren Transaktionssatz können die Aufträge auf verschiedenen Ketten abgeglichen und abgerechnet werden. Die Idee hat jedoch mehrere Herausforderungen zu bewältigen, einschließlich

• Rückzahlung verzögern
• Bestellabstimmung
• Gemeinsame Lösung
• Zeitaufwand und Honorarkosten.

Basierend auf dem Mechanismus und der Lösung der oben genannten Probleme schlagen wir unsere kettenübergreifende Handelslösung Portus vor.

Erinnern wir uns an den Transaktionssatz von Alice und Bobs Handel in der Technischen Herausforderung.

tx_1: Alice -> Bob-Hashsperre (p_A), Zeitsperre (t_1)tx_2: Bob -> Alice hashlock (p_A) timelock (t_2)

Die zwei Hauptprobleme des oben erwähnten Transaktionssatzes sind die verzögerte Rückzahlung und die Anforderung des Empfängers.

Das Problem mit der verzögerten Rückzahlung ist, dass der Rückzahlungsinitiator einer der Teilnehmer ist. Wenn Sie einen Dritten beauftragen, der für die Initiierung der Rückzahlung nicht von Vorteil ist, kann verhindert werden, dass die Initiierung vom Teilnehmer kontrolliert wird.

tx_3: Charlie -> Alice hashlock (p_C) timelock (t_1)tx_4: Alice -> Bob-Hashsperre (p_C) timelock (t_2)tx_5: Bob -> Charlie hashlock (p_C) timelock (t_3)

In diesem Transaktionssatz hashlock (p_C) ist ein von Charlie erstellter Hashlock. Charlie ist die dritte Partei, die wir oben erwähnt haben. Wenn die oben genannten Transaktionen gesendet werden, kann Charlie die Einlösung einleiten. Alice ist in der Lage, ihr Geld von zu fordern tx_3und Bob ist in der Lage, sein Geld von zu fordern tx_4. Nachdem Charlie sein Geld zurückgefordert hat, enthüllt er das Vorbild p_CDie vorteilhafteste Aktion für Alice und Bob ist es, ihr Geld einzufordern. Weder Alice noch Bob können von der Verzögerung der Rückzahlung profitieren. Alice, Bob und Charlie spielen unterschiedliche Rollen in der Struktur des Austauschs. Alice und Bob sind Benutzer. Charlie ist der Betreiber des Austauschs.

Ein weiteres Problem ist die Anforderung des Empfängers. Wie bereits erwähnt, ist die Gegenpartei noch nicht entschieden, wenn Benutzer ihre Bestellungen aufgeben. Angesichts dieses Problems geben wir Alice und Bob unterschiedliche Definitionen: Maker und Taker. Mit den drei Hauptaktionen des Handels an einer Börse kann die Transaktion wie folgt überarbeitet werden.

tx_E: Exchange -> Zeitsperre für Taker-Hashlock (p_E) (t_E)tx_T: Taker -> Maker Hashlock (p_E) Timelock (t_T)tx_M: Maker -> Exchange-Hashsperre (p_E) - Zeitsperre (t_M)

tx_E ist die passende Vervollständigungstransaktion, TXT ist die Transaktion des Abnehmers und tx_M ist die Maker-Transaktion.

Matching und Rücknahme

Ein vollständiger Prozess besteht aus mehreren Phasen.

1. Maker Order Settlement
2. Abrechnung der Abnehmerbestellung
3. Exchange-Matching-Verarbeitung
4. Rückzug

Da die anfängliche Bestellung vom Hersteller bereitgestellt wird, bieten wir dem Hersteller die Möglichkeit, das Guthaben an erster Stelle zu sperren, anstatt an der Schlange zu warten. Der folgende Vorgang wird dann automatisch ohne den Teilnehmer des Herstellers ausgeführt.

In Phase 1Der Hersteller wickelt den Herstellerauftrag ab, indem er die Herstellerauftragstransaktion unterzeichnet und überträgt tx_M.

In Phase 2Der Abnehmer gibt die Bestelldaten bekannt und fährt mit dem Umtausch fort. Die Vermittlungsstelle antwortet dann durch den Bestellvorgang. Taker erledigt den Abnehmerauftrag TXT.

In Phase 3zeigt der Austausch das Vorbild Sport um die Gelder einzulösen und die passende Abschluss-Transaktion zu erstellen und zu senden.

In Phase 4, Abnehmer und Hersteller können die Gelder in einlösen Taker-Haschock (p_E) und Herstellerhashlock (p_E) durch das enthüllte Vorbild Sport.

Abbrechen

Da der Hersteller das Recht haben sollte, die Bestellung des Herstellers zu stornieren, tx_M zurückerstattet werden können.

t_M ist eine bestimmte Zeit, die die Mittel in Exchange-Hashsperre (p_E) – Zeitsperre (t_M) kann nach dem an Maker zurückerstattet werden t_M.

Bei der Transaktion mit dem Abnehmer sollte auch der Rückerstattungsprozess berücksichtigt werden. In einer gemeinsamen Situation, tx_E und TXT werden nur erstellt, wenn die Aufträge übereinstimmen, daher sollte die Rückerstattungsfunktion für nicht erforderlich sein TXT. Allerdings, wenn der Hersteller erstattet tx_M nachdem die Bestellung abgeglichen ist (tx_E und TXT erstellt werden) und tauschen noch nicht ein tx_M durch das Vorbild zu enthüllen Sportwerden die Gelder des Empfängers gesperrt Herstellerhashlock (p_E). Obwohl dies keine normale Situation ist, müssen wir dennoch einen Rückerstattungsmechanismus für den Abnehmer entwerfen, um die Transaktion abzubrechen.

Die Zeitsperre setzte ein TXT beeinflusst auch die Rücknahmezeit für den Hersteller. Der Abnehmer kann die Transaktion nachträglich erstatten t_T. Andererseits muss der Hersteller die Transaktion vorher einlösen t_Toder der Abnehmer nimmt das Geld zurück.

Nach dem Anwenden der Lösung des Transaktionssatzes können die meisten der genannten Probleme gelöst werden. Es werden jedoch zwei Probleme festgestellt.

• Jede Transaktion muss in der Kette abgewickelt werden, was sehr zeit- und kostenintensiv ist.
• Jede Kategorie von Handelspaaren erfordert die Implementierung des Handlers zur Abwicklung des atomaren Transaktionssatzes. Mit anderen Worten, wenn das System die Unterstützung für eine neue Kette erweitert, nimmt der Entwicklungsaufwand quadratisch zu.

Das Problem des zeit- und kostenintensiven Austauschs ist den Schwierigkeiten des frühen dezentralen Austauschs sehr ähnlich. Benutzer schlagen ihre Anforderungen für das Aufgeben, Beanspruchen und Stornieren einer Bestellung vor. Der Auftragsmanager und der HTLC Atomic Transaction (HAT) -Handler bearbeiten dann die Anforderung und erstellen die entsprechenden Transaktionen für die Kette. Jede Bestellung muss in der Hauptkette abgewickelt werden, und jede Bestellung muss durch einen an den Smart-Vertrag gesendeten Befehl abgeglichen werden.

Dieses Problem kann auf verschiedene Arten gelöst werden. In DINNGO haben wir dieses Problem mithilfe einer Hybridstruktur gelöst, die die Off-Chain-Daten und die On-Chain-Abwicklung koordiniert. Obwohl Bitcoin nicht über eine so leistungsstarke Ressource verfügt, um die komplizierte Überprüfung und die folgende Lösung zu unterstützen, haben die Entwickler ihre Layer-2-Lösung implementiert, um das Skalierbarkeitsproblem zu lösen. HTLC wird auch im Rahmen dieser Anforderung, Lightning Network, vorgeschlagen.

Wenn der Benutzer eine Bestellung vorschlägt, werden die Informationen vom Matching-System verarbeitet und sofort an die Kette weitergeleitet. Für jede Aktion sind die Bestätigungszeit und die Bearbeitungsgebühr erforderlich. Durch die Anwendung einer Layer-2-Struktur müssen die temporären Handelsinformationen nicht in der Hauptkette abgerechnet werden.

Neben der Reduzierung der Kosten und der Bearbeitungszeit kann die zusätzliche Schicht das Problem der Erweiterung des Handelspaares zu einer neuen Kette lösen. Ähnlich wie bei dem in Lightning Network vorgeschlagenen Routing-Schema erfordert die Zahlung zwischen Alice und Bob nicht, dass ein direkter Kanal zwischen ihnen aufgebaut wird. Solange eine Route zwischen ihnen verfügbar ist, z. B. Alice zu Charlie, Charlie zu Dave, Dave zu Eva und Eva zu Bob, kann die Transaktion verarbeitet werden. Das Handelspaar erfordert daher nicht, dass die beteiligten Ketten dieselbe Hash-Funktion haben (eine verfügbare Route ist noch erforderlich), und nicht alle zwei Ketten müssen ein unabhängiges Handelssystem aufbauen.

Die Technologie der Blockchain wird rasant weiterentwickelt. Die Hauptidee der Blockchain besteht jedoch darin, zu verhindern, dass sie von einer bestimmten Person kontrolliert wird. Dies erschwert das Upgrade und die Migration einer Kette. Diese Grenzen haben ihr System aufgebaut, Benutzer gewonnen und ihre Werte bewiesen. Die kommenden Systeme werden verbessert, indem Probleme auf unterschiedliche Weise gelöst werden, um den Anforderungen in verschiedenen Szenarien gerecht zu werden. Angesichts der dezentralen Ausführung der einzelnen Blockketten wird es in Zukunft möglicherweise keine allwissende Kette geben. Stattdessen ist es vernünftiger, einen Weg zu finden, um zwischen den bestehenden und sogar den kommenden zu kommunizieren. Unter diesen Umständen ist ein Austausch eine der wichtigsten Infrastrukturen der Blockchain-Technologie. Dies ist auch der Grund, warum wir der Meinung sind, dass es kein weiterer zentraler Dienst sein sollte. Für einen ausgereiften dezentralen Dienst können verschiedene Blockchains unterschiedliche Betriebsressourcen bereitstellen, und Interoperabilität ist das letzte Puzzleteil. Um die Interoperabilität zwischen dem gesamten Blockchain-Netzwerk zu erreichen, möchte Portus eine Idee für eine leichte Lösung liefern, indem die Atomizität des Transaktionssatzes aus verschiedenen Ketten garantiert wird.