Kann Ethereum Rollups wie ein einziges Netzwerk wirken lassen?

Ein Händler in einer Devcon-Demo unterzeichnete eine Order auf einem Ethereum-Rollup, kaufte Token unter Nutzung von Liquidität auf dem Mainnet und erhielt sie auf dem Rollup zurück. Der Handel zeigt, wie Nutzer einen tieferen Markt erreichen könnten, ohne selbst Gelder zu bewegen – ein Ansatz, den Gnosis für seine Standardkonfiguration im Frühjahr 2027 anstrebt.

Das Ethereum Economic Zone-Team hat einen Handel demonstriert, bei dem ein Nutzer eine Order im experimentellen Rollup-X-Netzwerk unterzeichnete, ein CoW-Swap-Solver sie unter Nutzung von Liquidität des Ethereum-Mainnets füllte und die gekauften Token wieder auf dem Rollup ankamen. Die Demo zeigt, wie ein Händler einen tieferen Markt auf dem Mainnet erreichen könnte, ohne zuerst Gelder dorthin zu senden und auf deren Ankunft zu warten, bevor er die Order platziert.

Das Team präsentierte den Handel auf der Devcon am 4. November, wie crypto.news berichtete. Der Unterschied ist wichtig, wenn sich Preise schnell bewegen, da sich ein Kurs, der verfügbar war, als ein Händler begann, Gelder zu bewegen, ändern kann, bevor die Gelder handelsbereit sind.

Gnosis strebt das Frühjahr 2027 an, um das Design zu seinem Standard zu machen. Für Händler wird der praktische Test sein, ob ihre Wallets und Trading-Apps die Route anbieten können und ob der auf dem Mainnet verfügbare Preis nach Ausführungskosten noch lohnenswert ist.

Wie der Handel über zwei Ausführungsumgebungen hinweg funktionieren würde

Das Ethereum Economic Zone-Team begann mit einer Oktober-Transaktion mit 0,001 ETH und einer Aktualisierung des Rollup-Zustands. Der Devcon-Swap übertrug dasselbe Koordinationsproblem in ein Umfeld, das Händler wiedererkennen. Er musste eine Order gegen Liquidität auf einer anderen Chain erfüllen und den resultierenden Vermögenswert dorthin liefern, wo der Nutzer begonnen hatte.

Für einen Händler beschreibt die Order ein Ergebnis. Ein Verkäufer möchte einen Vermögenswert gegen einen anderen tauschen, vorbehaltlich der Bedingungen der Order, und das Ergebnis auf dem Rollup erhalten. Der Solver übernimmt die Verantwortung dafür, einen Ausführungspfad zu finden. Der Unterschied ist wichtig, weil der Nutzer ein Ergebnis autorisieren kann, ohne zu entscheiden, welchen Pool der Solver nutzen wird, oder eine separate Transaktion für jede Operation vorzubereiten.

Im Devcon-Beispiel umfasste dieser Pfad das Ethereum-Mainnet. Die Handelsliquidität blieb dort, während die Order des Nutzers auf Rollup X entstand und die gekauften Vermögenswerte dorthin zurückkehrten. Die Demonstration adressierte somit ein Problem, das selbst dann auftreten kann, wenn die Anwendungen jedes Netzwerks für sich korrekt funktionieren. Ein Händler kann Gelder auf einer Chain mit einem flachen Markt für das gewünschte Paar haben, während die beste Ausführung anderswo verfügbar ist.

Eine Route mit separaten Schritten setzt den Nutzer Entscheidungen entlang des Weges aus. Die erste Übertragung kann abgeschlossen sein, während sich der Kurs, den der Nutzer gesehen hat, geändert hat. Zu diesem Zeitpunkt muss der Nutzer entweder den aktuellen Preis akzeptieren, warten oder die Gelder erneut bewegen. Eine koordinierte Route kann die Vermögensbewegungen an die Fertigstellung der gesamten Order knüpfen, vorausgesetzt, die teilnehmende Infrastruktur kann die Operation im vereinbarten Ausführungsfenster durchführen.

Der praktische Unterschied besteht zwischen einer Route, die Lieferung verspricht, und einer Route, die die Teiloperationen miteinander verbindet. Ein Dienst kann einen Cross-Chain-Handel einfach erscheinen lassen, indem er die Verantwortung für die Lieferung selbst übernimmt. Das Design in der Demo gibt der Anwendung eine Möglichkeit, das Ergebnis auf einer Chain mit der Ausführung auf einer anderen zu verknüpfen. Welcher Ansatz die bessere Erfahrung bietet, hängt vom Preis, den verfügbaren Vermögenswerten und den Bedingungen ab, unter denen jeder Dienst die Order liefert.

Hinter der Signatur des Nutzers steckt noch Arbeit. Eine Anwendung muss die Bedingungen darstellen, der Solver muss die Route finden und bepreisen, und teilnehmende Netzwerke müssen sich auf den relevanten Zustand einigen. Ein Produktionssystem muss Ausfälle an jedem dieser Orte bewältigen. Die Anwendung kann die Schnittstelle vereinfachen, ohne diese Aufgaben verschwinden zu lassen.

Für eine Wallet ist ein ebenso praktischer Test der Transaktionsdatensatz, den sie nach Ablauf der Order anzeigen kann. Wenn ein Nutzer einmal signiert und ein Handel erfolgreich ist, sollte der Nutzer das erhaltene Asset und das Konto, das es erhalten hat, sehen können. Wenn die Route fehlschlägt, braucht die Wallet weiterhin eine Möglichkeit, eine abgelaufene Order von einer Transaktion zu unterscheiden, die auf die Abwicklung wartet. Dies ist während einer Marktbewegung wichtig, wenn ein Trader eine zweite Order platzieren möchte und wissen muss, ob die erste noch ausgeführt werden kann.

Worauf sich Netzwerke einigen müssen, bevor sie gemeinsam ausführen können

Eine Blockchain zeichnet mehr als nur Guthaben auf. Ihr Zustand umfasst Informationen, die von Anwendungen genutzt werden, wie Kontoberechtigungen, Vertragsguthaben und den Status von Transaktionen. Ein Vertrag, der sich auf ein Ergebnis von einer anderen Chain verlassen möchte, benötigt einen Nachweis über diesen Zustand. Der Nachweis muss verfügbar sein, wenn der Vertrag das Ergebnis verwenden muss.

Gnosis beschreibt zwei Bedingungen für Netzwerke, die dem EEZ-Design beitreten. Sie müssen innerhalb eines Ethereum-Slots einen Nachweis erzeugen und im Falle einer Reorganisation Ethereum folgen. Gnosis stellt diese als Bedingungen an ein verbundenes Netzwerk dar und überlässt einige Implementierungsentscheidungen den einzelnen Teilnehmern.

Ein Slot gibt Ingenieuren eine Frist. Wenn ein Netzwerk länger als die verfügbare Zeit benötigt, um den erforderlichen Nachweis zu erzeugen, kann sich die andere Seite nicht innerhalb desselben Fensters darauf verlassen. Ein Beweissystem, das bei typischen Blöcken gut abschneidet, muss sich dennoch mit ungewöhnlich anspruchsvollen Arbeitslasten, Unterbrechungen und Konkurrenz um Rechenressourcen auseinandersetzen.

Die zweite Bedingung betrifft, was geschieht, wenn sich die jüngste Ethereum-Historie ändert. Eine Transaktion auf einem anderen Netzwerk hat sich möglicherweise auf ein Ereignis in einem jüngsten Mainnet-Block verlassen. Wenn ein konkurrierender Block ihn ersetzt, benötigt das verbundene System Regeln für den Umgang mit der abhängigen Transaktion. Die Ausrichtung begrenzt die Möglichkeit, dass eine Seite ein Ergebnis auf der Grundlage eines Mainnet-Ereignisses beibehält, das nicht mehr zur akzeptierten Chain gehört.

Diese Beziehung ist für Nutzer wichtig, weil eine koordinierte Transaktion und die endgültige Abwicklung unterschiedliche Eigenschaften beschreiben. Die koordinierte Ausführung betrifft die Frage, ob die Schritte gemeinsam abgeschlossen werden können. Die endgültige Abwicklung betrifft den Zeitpunkt, zu dem Teilnehmer das Ergebnis nach den Regeln der beteiligten Netzwerke als abgeschlossen betrachten können. Eine Wallet kann eine Ansicht der Operation anbieten und dennoch eine einbezogene Transaktion von einer unterscheiden, die den für ein Geschäft erforderlichen Abwicklungsstatus erreicht hat.

Frühere Ingenieurarbeiten von Gnosis befassten sich mit Block-Root-Commitments, Gaslimits und der Frage, wie Upgrades durchgeführt werden würden. Diese Entscheidungen beeinflussen, wie die Netzwerke die Ergebnisse des jeweils anderen erkennen können und wie viel Arbeit Anwendungen von ihnen verlangen können. Der Oktober-Meilenstein brachte eine einfache Operation auf das Mainnet, während die November-Demonstrationen Entwicklern vielfältigere Arbeitslasten zum Ausprobieren gaben.

Wohin das Design über den Handel hinausgehen könnte

Die Safe-Demonstration wandte denselben Ansatz auf das Wallet-Eigentum an. Eine Treasury, die separate Konten über Chains hinweg verwendet, kann eine Lücke zwischen dem Entfernen eines Signers auf einem Netzwerk und der Aktualisierung von Berechtigungen anderswo erleben. Das Beispiel zeigte, wie ein Rollup eine auf dem Mainnet vorgenommene Eigentumsänderung innerhalb derselben Transaktion verifizieren könnte.

Eine dritte Demo verifizierte eine Falcon-Post-Quanten-Signatur auf dem Rollup und nutzte das Ergebnis, um eine Mainnet-Überweisung zu autorisieren. Das Team berichtete von 91 % geringerem Gasverbrauch im Vergleich zur direkten Durchführung der Verifizierung auf dem Mainnet. Die gemessene Einsparung betraf diese Verifizierungsübung, und eine Produktionsanwendung müsste ihre vollständigen Ausführungs- und Abwicklungskosten berücksichtigen.

Eine Signatur lässt noch einen Markt für die Ausführung

Die Swap-Route verlagert einen Teil der Arbeit weg von der Person, die eine Order platziert. Ein Solver muss entscheiden, wo er sie ausführt, Gebühren berücksichtigen und die erforderlichen Operationen zur Ausführung einreichen. Ein Nutzer kann ein einziges Angebot erhalten, obwohl der Solver mehrere Schritte in den angebotenen Betrag eingepreist hat.

Diese Regelung ist am nützlichsten, wenn die auf einem anderen Netzwerk verfügbare Liquidität den Handel um genug verbessert, um die Kosten der Erreichung zu decken. Eine kleine Order in einem tiefen lokalen Markt kann lokal günstiger auszuführen sein. Eine größere Order in einem flachen Pool könnte selbst nach den zusätzlichen Ausführungskosten einen besseren Preis aus der Mainnet-Liquidität erhalten.

Es ist auch wichtig, was mit fehlgeschlagenen Versuchen geschieht. Das Zurücksetzen der Asset-Bewegungen verhindert, dass der Trader nur mit einem Bein des beabsichtigten Handels zurückbleibt. Eine Anwendung oder ein Solver kann dennoch Kosten für die Anordnung oder den Versuch der Ausführung verursachen, je nachdem, wie die Route implementiert ist. In einem Produktionsmarkt können diese Kosten beeinflussen, welche Orders Solver bereit sind auszuführen und wie sie ihre Angebote bepreisen.

Ein guter Vergleich für Trader würde dieselbe Ordergröße, dasselbe Token-Paar und dasselbe Zeitfenster verwenden. Der nach Gebühren erhaltene Preis kann dann mit einem lokalen Swap oder einer Route verglichen werden, die Gelder in separaten Schritten überbrückt. Die Anzahl der Klicks erfasst den Komfort. Der netto erhaltene Betrag erfasst den Trade selbst.

Wie das Projekt von einem Vorschlag zu einem Devnet gelangte

Das Projekt wurde im Frühjahr öffentlich auf dem EthCC vorgestellt, von Gnosis und ZisK, mit Unterstützung der Ethereum Foundation. Der ursprüngliche Vorschlag betraf Liquidität und Anwendungen, die sich auf verschiedene Layer-2-Netzwerke verteilt hatten. Rollup X gibt Entwicklern eine Umgebung, in der sie testen können, wie eine gemeinsame Transaktion diese Anwendungen nutzen kann.

Es gibt einen Grund, warum die Wahl der Demonstration wichtig ist. Das Verschieben eines kleinen ETH-Betrags zwischen Umgebungen testet eine relativ direkte Operation. Ein Swap führt die Notwendigkeit ein, eine Order gegen Marktliquidität zu erfüllen und einen Vermögenswert zurückzugeben. Eine Änderung der Eigentümerschaft eines Safe beinhaltet Berechtigungen. Die Signaturverifikation erfordert, dass eine Umgebung eine Prüfung durchführt und eine andere auf deren Ergebnis reagiert. Jede testet eine andere Abhängigkeit.

Eine Route, die für eine dieser Operationen funktioniert, kann für eine andere unpraktisch sein. Ein Swap muss sich mit Preisen und Liquidität auseinandersetzen, die sich kontinuierlich bewegen. Eine Eigentümeränderung ist weniger empfindlich gegenüber dem Marktpreis, kann aber folgenschwerere Fehlermodi haben. Eine Verifikationsanwendung kann davon profitieren, Rechenarbeit anderswo zu erledigen, selbst wenn es keinen wirtschaftlichen Grund gibt, Gelder zwischen Netzwerken zu bewegen.

Die gemeinsame Anforderung ist, dass sich der empfangende Vertrag auf die Informationen zu dem Zeitpunkt verlassen kann, zu dem er sie benötigt. Das setzt die Software unter Druck, die die Verbindungen aufrechterhält. Eine Anwendung kann nur dann eine einfache Schnittstelle bieten, wenn der Ausführungspfad den erforderlichen Zustand handhabt und das erwartete Ergebnis zurückgibt. In einem Live-Produkt müssten Entwickler entscheiden, welche Operationen es wert sind, auf diesen Pfad gelegt zu werden, und welche unabhängig laufen können.

Gnosis' Argument, die Technologie zum Standard zu machen, beruht teilweise darauf, was Anwendungen vermeiden könnten zu duplizieren. Ein Team, das auf einem neuen Netzwerk aufbaut, müsste sonst möglicherweise lokale Liquidität für eine lange Liste von Märkten finanzieren. Die Fähigkeit, Mainnet-Pools zu erreichen, könnte es ihm ermöglichen, Handel auf einem Paar anzubieten, bevor ein dedizierter lokaler Pool rentabel wird. Für einen lokalen Liquiditätsanbieter schafft dieselbe Wahl Konkurrenz durch eine andere Ausführungsquelle.

Die Auswirkung auf Nutzer lässt sich am einfachsten in Produkten messen, die beide Routen offenlegen. Eine Wallet könnte eine lokale Ausführung mit einer Mainnet-Ausführung für dieselbe Order vergleichen und den Nettobetrag auf derselben Zielkette anzeigen. Ein Treasury-Tool könnte dokumentieren, wie viele separate Transaktionen erforderlich sind, um eine Berechtigungsänderung anzuwenden. Diese Tests würden zeigen, wo der Ansatz tatsächliche Ausführungskosten oder operativen Aufwand verändert.

Der Zeitplan ist wichtig, weil eine erfolgreiche Demonstration viel einfacher zu betreiben sein kann als ein Dienst mit vielen Nutzern und Anwendungen. Ein Live-System muss gleichzeitige Anfragen, unterschiedliche Marktbedingungen und Softwareänderungen bewältigen. Bestehende Gnosis-Chain-Anwendungen durch den Umzug zu bringen, würde mehr dieser Abhängigkeiten testen als die Devcon-Beispiele allein.

Was der Preis bei einem Cross-Chain-Swap abdecken müsste

Ein Trader vergleicht den Betrag des gekauften Vermögenswerts, der nach Kosten ankommt. Ein lokaler Pool hat seine eigene Handelsgebühr und Preisauswirkung. Eine Mainnet-Route kann tiefere Liquidität bieten, aber sie kann mehr Ausführungsarbeit erfordern und Kosten für ihre Nutzung verursachen. Ein Solver, der zwischen Routen entscheidet, muss den besseren Pool-Preis gegen diese Kosten abwägen.

Stellen Sie sich vor, ein lokaler Pool würde nach allen Gebühren einen Vermögenswert im Wert von 9.900 $ für eine Order mit einem Referenzwert von 10.000 $ liefern. Eine Cross-Chain-Route, die den Trade vor Ausführungskosten für 9.980 $ füllen kann, hat bis zu 80 $ Spielraum, bevor das lokale Quote besser wird. Wenn das Erreichen des besseren Pools 30 $ kostet, liefert die Cross-Chain-Route 9.950 $. Bei 100 $ zusätzlicher Kosten bietet die lokale Route mehr. Die Zahlen veranschaulichen den Vergleich und beschreiben kein Live-Quote.

Die Ordergröße verändert diese Berechnung. Ein größerer Trade kann den Preis in einem flachen Pool weiter bewegen und gibt dem Solver mehr Grund, einen tieferen Markt zu erreichen. Ein kleiner Trade kann kaum lokale Preisauswirkungen haben und zu wenig Ersparnis übrig lassen, um die Cross-Chain-Route zu decken. Selbst bei demselben Token-Paar kann sich die nützliche Route im Laufe eines Tages ändern, wenn sich Liquidität und Netzwerkkosten verschieben.

Solver müssen außerdem fehlgeschlagene Versuche und die Zeit, die sie für die Suche nach Routen aufwenden, einpreisen. Eine fehlgeschlagene Operation kann dazu führen, dass die Asset-Bewegungen des Nutzers zurückgesetzt werden, während die Parteien, die die Order arrangieren, dennoch mit Ausgaben für den Ausführungsversuch konfrontiert sein können. Die Auswirkung des Designs auf den Spread, den ein Trader sieht, hängt davon ab, wie eine Live-Implementierung diese Kosten zuordnet und wie groß der Wettbewerb unter den Firmen ist, die Quotes anbieten.

Für eine Wallet, die dieses Design integriert, sind die wichtigen Informationen diejenigen, die der Nutzer vergleichen kann. Ein Quote, der den mindestens gelieferten Betrag und das Netzwerk angibt, auf dem er ankommen wird, gibt dem Trader eine Möglichkeit, das Ergebnis zu bewerten. Eine Oberfläche, die einen Klick oder eine Signatur betont, zeigt etwas über den Komfort, während Preis und Lieferbedingungen zeigen, ob die Route die Order bedient.

Ein Handelsplatz, der das Design in Betracht zieht, müsste entscheiden, was er Kunden über die Abhängigkeiten eines Quotes zeigt. Eine Route könnte vollständig dort ausgeführt werden, wo der Nutzer Mittel hält. Eine andere könnte Mainnet-Liquidität einbeziehen und sich darauf verlassen, dass ein Proof innerhalb eines Slots bereitsteht. Selbst wenn beide Quotes denselben Token und denselben Betrag zeigen, können sie unterschiedliche Ablaufregeln und unterschiedliche Gründe für ein Scheitern haben. Die Oberfläche müsste den Mindestbetrag kommunizieren, den ein Kunde akzeptiert, und was passiert, wenn der Solver ihn nicht liefern kann.

Anwendungen müssen außerdem herausarbeiten, wie sie genügend vergleichbare Daten sammeln würden, um zu erkennen, warum eine Route mehr kostet. Eine nützliche Reihe würde dasselbe Paar und dieselben Trade-Größen in denselben Netzwerken umfassen, wobei die Quotes zeitlich nah beieinander erfasst werden. Ein einzelner Trade eines ungewöhnlich illiquiden Paares könnte die Fähigkeit, einen anderen Markt zu erreichen, wertvoller erscheinen lassen, als sie es für alltägliche Orders ist. Das umgekehrte Problem kann bei einem großen Paar auftreten, das bereits günstig auf dem Rollup des Nutzers gehandelt wird. Der Ausführungspreis, die enthaltenen Gebühren und die Ablaufbedingungen müssen in dem Vergleich gemeinsam betrachtet werden.

Safe macht die Cross-Chain-Autorität zu einem Teil des Problems

Eine Treasury könnte ein Konto für regelmäßige Zahlungen und ein anderes für das Halten von Assets in einem anderen Netzwerk verwenden. Wenn sie die Personen ändert, die zur Genehmigung von Ausgaben berechtigt sind, muss jemand sicherstellen, dass die Änderung dort widergespiegelt wird, wo die Assets gehalten werden. Getrennte Aktualisierungen schaffen Möglichkeiten, dass eine veraltete Signer-Liste auf einem seltener genutzten Konto aktiv bleibt.

Die Safe-Demonstration zeigte, wie eine Anwendung eine Mainnet-Eigentümeränderung innerhalb einer koordinierten Transaktion mit einem Rollup nutzen könnte. Ihr Nutzen hängt davon ab, wie die Treasury beschlossen hat, Autorität zuzuweisen. Eine Organisation könnte wollen, dass Mainnet eine gemeinsame Gruppe von Signern bestimmt, während sie eine separate Richtlinie für ein lokales Ausgabenkonto beibehält, das einem bestimmten Team dient.

Eine gemeinsame Autoritätsstruktur kann doppelte Arbeit reduzieren. Sie macht auch den Umgang mit Fehlern wichtiger, weil eine Änderung Folgen an mehreren Standorten haben kann. Eine Treasury müsste verstehen, wie ihre Konten sich erholen, wenn eine Aktualisierung falsch ist, wer eine Korrektur autorisieren kann und wie sich eine verbundene Chain verhält, wenn sie kein aktuelles Ergebnis erhalten kann.

Eine Organisation, die das Design bewertet, würde daher fragen, welche Operation sie koordinieren möchte. Das Lesen einer Signer-Liste, das Aktualisieren des Eigentums und das Bewegen von Treasury-Assets haben unterschiedliche Konsequenzen. Der Wert, eine davon innerhalb einer gemeinsamen Transaktion auszuführen, belegt nicht, dass eine Organisation jede Entscheidung an dasselbe Konto delegieren sollte.

Das institutionelle Interesse geht über die Devcon-Bühne hinaus. Consensys kündigte ein Interoperabilitätssystem für Banken an und erklärte, dass es den EEZ-Standard unterstützen will. Für eine Bank würde die Kompatibilität neben Fragen dazu stehen, wer das System nutzen kann, welche Kontrollen für jede Operation gelten und wie es das Ergebnis in bestehenden Systemen erfasst.

Der Safe-Fall legt eine andere Reihe von Produkttests nahe. Ein Team könnte wollen, dass Signer in einem Netzwerk eine Operation genehmigen, die nur Assets in einem anderen betrifft. Das wirft die Frage auf, ob ein lokal entfernter Signer noch eine zuvor eingereichte netzwerkübergreifende Operation autorisieren kann. Die Antwort hängt davon ab, wie die Anwendung den Kontostatus liest und was sie als Zeitpunkt der Autorisierung behandelt. Das sind Dinge, die eine Anwendung festlegen muss, selbst wenn das zugrunde liegende Protokoll in der Lage ist, die Nachricht zu übertragen.

Was die Falcon-Demo über die Auslagerung von Berechnungen aussagt

Die maßgebliche Demonstration nutzte ein Rollup, um eine Falcon-Signatur zu verifizieren, und lieferte dieses Ergebnis an eine Mainnet-Aktion. Das Team berichtete von einer Reduzierung des Gasverbrauchs um 91 % im Vergleich zur Verifizierung auf dem Mainnet. Das Beispiel hat einen engeren Geltungsbereich als eine Aussage über die Kosten jeder Transaktion, die das Design nutzen könnte. Es vergleicht eine bestimmte Operation über zwei Ausführungspfade hinweg.

Die Chance besteht darin, eine rechenintensive Prüfung in einer dafür geeigneten Umgebung auszuführen, während ein anderer Vertrag sich auf das Ergebnis verlässt. Eine Anwendung, die eine Prüfung nur selten durchführt, könnte die Einsparungen anders bewerten als eine, die sie bei jeder Order wiederholt. Die Entscheidung hängt auch davon ab, wie die Anwendung das Ergebnis validiert und welche weiteren Schritte sie abschließen muss, um es zu nutzen.

Die Post-Quanten-Verifizierung ist eine Anwendung dieses Musters. Ein Vertrag könnte andere Informationen aus einer verbundenen Umgebung benötigen, bevor er fortfahren kann, etwa ob ein Konto das Recht hat, eine Operation auszuführen. Das gemeinsame Problem besteht darin, ein Ergebnis innerhalb desselben Ausführungsfensters verfügbar zu machen. Verschiedene Prüfungen können sehr unterschiedliche Anforderungen an Berechnung und Nachweis haben.

Für einen Nutzer bestimmt die Unterstützung eines Signaturschemas in einer Anwendung nicht die Sicherheit jeder Wallet oder Transaktion auf der Chain. Die Demo befasste sich mit der Verifizierung und Autorisierung für die spezifische Überweisung. Eine Änderung der Regeln, nach denen Wallets im Allgemeinen Transaktionen signieren, würde andere Entscheidungen über Software, Kompatibilität und darüber, welche Konten die Änderungen übernehmen, erfordern.

Eine ähnliche Unterscheidung gilt für Entwickler, die die Falcon-Demonstration bewerten. Das Gas, das der Vertrag beim Lesen eines Verifizierungsergebnisses verbraucht, und die Kosten für die Erzeugung dieses Ergebnisses an anderer Stelle gehören zu unterschiedlichen Ausführungsumgebungen. Die Messung des Ersteren erfasst eine reale Einschränkung für eine Anwendung, die andernfalls die Verifizierung auf dem Mainnet ausführen müsste. Ein Dienst, der entscheidet, ob er die Funktion anbieten kann, muss auch Letzteres berücksichtigen. Er muss außerdem wissen, ob die Prüfung unter Last abgeschlossen werden kann, wenn viele Anfragen um dieselbe Kapazität konkurrieren könnten.

Gnosis wird bestehende Anwendungen durch den Übergang führen müssen

GnosisDAO genehmigte im August über GIP 153 den Wechsel von einem eigenständigen Netzwerk zu einem EEZ-Rollup. Die Migration ist wichtig, weil bestehende Nutzer und Anwendungen Guthaben, Adressen und Abhängigkeiten haben, die an die laufende Chain gebunden sind. Für sie ist die Übernahme einer neuen Ausführungs- und Abwicklungsregelung eine Änderung der Infrastruktur, die sie bereits nutzen.

Die Fragen, die eine laufende Anwendung beantworten muss, unterscheiden sich von denen für ein Entwicklungsnetzwerk. Ihre Nutzer müssen wissen, wie Guthaben übertragen werden, welche Wallets und Infrastrukturanbieter die Migration unterstützen und wo sie während des Übergangs eine verlässliche Aufzeichnung der Aktivität erhalten können. Handelsplattformen müssen die Möglichkeit berücksichtigen, dass Integrationen zu unterschiedlichen Zeiten verfügbar werden.

Ein Rollup, das auf Mainnet-Märkte zugreifen kann, könnte möglicherweise Routen anbieten, bevor es eigene tiefe Pools für jedes Token-Paar aufbaut. Eine Chain mit etablierter Liquidität hat eine andere Entscheidung zu treffen. Ihre Anwendungen können zwischen lokaler Ausführung und einer gemeinsamen Route wählen, und die bereits auf der Chain befindlichen Liquiditätsanbieter können sehen, wie sich diese Entscheidungen auf die Aktivität in ihren Pools auswirken.

Die Migration wird auch den Unterschied zwischen dem Start eines Netzwerks und der Etablierung einer Funktion als Standard für Nutzer testen. Ein erster Block kann zeigen, dass die neue Chain läuft. Eine Standardroute für Nutzer erfordert, dass Wallets, Anwendungen und andere Anbieter den neuen Pfad in der gewöhnlichen Aktivität nutzen. Frühere Berichte nannten ein Ziel um den Jahreswechsel für eine erste Bereitstellung. Das November-Update von Gnosis nennt Frühjahr 2027 als Ziel für den Standardbetrieb.

Gnosis bietet Entwicklern einen Ort, um diese Fragen anhand einer Bereitstellung mit bestehenden Anwendungen zu stellen. Die Migration würde Ausführung, Wallet-Unterstützung und Betriebsverfahren unter denselben Zeitplan stellen und es ermöglichen, zu verfolgen, wie das Team mit Verzögerungen oder teilweisen Integrationen umgeht. Ihr November-Update nennt Frühjahr 2027 als Ziel dafür, das Design zum Standard zu machen. Die Devcon-Operationen fanden auf Rollup X statt.

Worauf zu achten ist

• Unterstützte Routen. Wallets und Anwendungen, die die Netzwerke veröffentlichen, auf denen dieselbe Operation verfügbar ist.
• Ausführungsquotes. Vergleichbare Nettoausgabe und Raten fehlgeschlagener Aufträge für lokale und netzwerkübergreifende Trades.
• Slot-Leistung. Wiederholte Tests, die die Verfügbarkeit von Proofs und die Wiederherstellung bei Ethereum-Reorganisationen zeigen.
• Treasury-Berechtigungen. Veröffentlichter Umfang, Ablauf und Widerrufsregeln für Safe-Integrationen.
• Gnosis-Meilensteine. Öffentliche Migrationstests und Fortschritt in Richtung des Ziels für Frühjahr 2027.

FAQ