- Vitalik Buterin hat eine Rollup-übergreifende Lösung vorgeschlagen, die es ermöglicht, Transaktionen zwischen zwei Rollups zu senden.
- Die Lösung stützt sich auf einen Vermittler, der das Senden von Transaktionen von A nach B ermöglicht.
Ethereum-Erfinder Vitalik Buterin hat einen Vorschlag unterbreitet, der die Kommunikation zwischen zwei Protokollen unter Verwendung von Skalierungslösungen der zweiten Schicht, bekannt als Rollups, ermöglichen würde. Mit dem Titel „Cross-Rollup DEX with smart contracts only on the destination side“ erlaubt der Vorschlag einem Benutzer, Geld von einem Rollup zu einem anderen zu senden, wenn nur einer der beiden Benutzer volle Smart Contract-Unterstützung hat und der andere nur „einfache Transaktionen“ verwenden kann.
Laut Vitalik’s Konzept sind Rollups eine Reihe von Off-Chain-Transaktionen, die in einem Ethereum-kompatiblen Smart Contract zusammengefasst werden. Dieser Smart Contract ermöglicht es Nutzern, sicher Transaktionen zu tätigen, die dann in der Main-Chain aggregiert werden. Allerdings hat die Lösung Komplikationen.
Rollups haben verschiedene Typen und können einzigartige Smart Contracts verwenden. Zum Beispiel arbeiten Optimistic Rollups (ORs) mit einem Transaktionsaggregator, der eine kleine Menge an Informationen verwendet, andere wie ZK-Rollups können mit einem Zero-Knowledge-Proof-Schema arbeiten. Aufgrund ihrer Eigenschaften ist es für Rollups daher schwierig, miteinander zu interagieren.
Wie funktioniert die Lösung von Buterin?
In seinem Vorschlag erklärt Buterin, dass eine der vielen Implementierungen, die seine Lösung haben könnte, auf einer dezentralen Börse ist, bei welcher „Alice“, ein Benutzer ist, der Münzen mit zwei verschiedenen Rollups tauschen möchte, und Ivan, der Vermittler.
Hierfür ist es notwendig, dass einer der beiden Rollups ein „Memo-Feld“ hat oder die Verwendung von niedrigen Stückelungen des in einer Transaktion gesendeten Wertes als Memo erlaubt. Der Intermediär muss indes Geldmittel in beiden Rollups (A und B) Smart Contracts haben, daher wird der Intermediär IVAN_A und IVAN_B genannt.
Alice sendet Geldmittel von Adresse ALICE_A an Adresse IVAN_A unter Verwendung der ersten der beiden Lösungen der zweiten Schicht. Außerdem muss Rollup B in der Lage sein, Buterins vorgeschlagene Regel zu befolgen:
Wenn jemand eine Transaktion mit TRADE_VALUE Coins an IVAN_A sendet, die eine Adresse DESTINATION als Memo enthält, dann kann er nach MIN_REDEMPTION_DELAY-Blöcken eine Transaktion an IVAN_B senden, die einen Beweis für den Transfer enthält, der eine Abhebung von TRADE_VALUE Coins an Adresse DESTINATION in die Warteschlange stellt.
In den Memos kann Alice angeben, dass sie die Empfängerin der Gelder ist, die von IVAN_B an ALICE_B gehen werden. Der Empfänger erhält die Gelder dann nach einer bestimmten Zeitspanne. Auf diese Weise können Transaktionen so gestapelt und indiziert werden, dass sie mit den Transaktionen von Rollup A übereinstimmen. Buterin hat die Funktionsweise seiner Lösung wie folgt zusammengefasst:
Alice sendet eine Transaktion an IVAN_A mit N Coins und einem Memo ALICE_B. Ivan sendet eine Transaktion mit TRADE_VALUE * (1 – fee) Coins über IVAN_B an ALICE_B.
Buterin erklärte, dass in einem „Worst-Case-Szenario“ der Vermittler die Coins nicht an die Adresse von ALICE_B senden könnte, aber glaubt, dass die Benutzerin warten kann, bis Rollup A die Transaktion bestätigt, um „einen alternativen Weg zu finden“, um ihre Gelder an Rollup B zu senden und „die Gelder selbst zu beanspruchen.“ Buterin schlussfolgert:
Die wichtigste Einschränkung des Schemas ist, dass IVAN_B eine große Menge an Kapital halten muss, um sicherzustellen, dass alle Absender bezahlt werden.
