Sei

Sei ist eine Ausführungsinfrastruktur für Anwendungen, die viele Vorgänge in einem öffentlichen Netzwerk erfassen müssen. Die EVM-Umgebung erlaubt es, die Sprache Solidity und bekannte Entwicklungswerkzeuge beizubehalten, während das Netzwerk Transaktionen, die sich nicht gegenseitig blockieren, parallel verarbeitet.

Für ein Produkt lautet die entscheidende Frage, welche Vorgänge denselben Zustand teilen: Transfers zwischen verschiedenen Nutzern können sich anders verhalten als viele Aufträge, die denselben Contract verändern. Die Auswahl erfordert die Messung des tatsächlichen Geschäftsablaufs, nicht die Übertragung einer Durchsatzkennzahl des Protokolls auf die Anwendung.

Die parallele Ausführung soll mehrere Prozessorkerne nutzen, ohne das Ergebnis zu verändern, das eine gültige sequenzielle Ausführung liefern würde. Wenn zwei Transaktionen von denselben Daten abhängen, muss das System diese Abhängigkeiten auflösen, um die Konsistenz des Zustands zu wahren.

Der Contract definiert weiterhin Berechtigungen, Salden und Zustandsübergänge; die Anwendung verbindet sich per RPC und signiert die Vorgänge aus einer Wallet. Bei Metlabs gehört zu den Integrationskriterien, Events, Gas-Schätzungen, Fehlerbehandlung und Bestätigungen zu prüfen, bevor dieser Ablauf an die Buchhaltung oder das Backend des Kunden angebunden wird.

Zur Bewertung der Parallelisierung werden mindestens zwei Lastprofile verglichen: Vorgänge auf unabhängigen Konten oder Datensätzen und Vorgänge, die denselben gemeinsamen Zustand aktualisieren. Ein globaler Zähler, ein gemeinsames Guthaben oder eine einzige Warteschlange können die Verarbeitung serialisieren. Das Ergebnis des Prototyps muss Latenz und Fehler des gesamten Ablaufs erfassen, einschließlich Wallet, RPC und Indexierung, nicht nur die Ausführung innerhalb des Netzwerks.

Sei kann sich für digitale Marktplätze und Anwendungen mit häufigen Interaktionen eignen, wenn das Team in Solidity arbeiten muss. Es erlaubt außerdem, eine Erweiterung von einem anderen EVM-Netzwerk aus zu prüfen, ohne zwingend die Sprache der Contracts zu wechseln.

Bevor wir uns für das Netzwerk entscheiden, prüfen wir, welche Vermögenswerte, Oracles und Dienste das Produkt benötigt und ob sie im gewählten Netzwerk verfügbar sind. Ein Prototyp muss gleichzeitige Vorgänge, RPC-Ausfälle und Lastspitzen abbilden. Auf dieser Grundlage lässt sich entscheiden, ob der Ausführungsvorteil es rechtfertigt, ein weiteres Netzwerk in den Support und den täglichen Betrieb aufzunehmen.

In einem Marktplatz für digitale Vermögenswerte kann zum Beispiel jedes Angebot einen eigenen Zustand und eigene Berechtigungen haben, während Zahlungen und Stornierungen um dessen Änderung konkurrieren. Die Tests müssen nachweisen, dass ein Angebot nicht zweimal angenommen wird und dass das Backend das Ergebnis nach einem Verbindungsabbruch rekonstruieren kann. Geprüft wird auch die tatsächliche Kompatibilität von Oracles, Explorern und Deployment-Werkzeugen mit dem eingesetzten Contract, statt sie wegen der gemeinsamen EVM als gegeben anzunehmen.

EVM-Kompatibilität bedeutet weder, die Sicherheit von Ethereum zu teilen, noch über alle seine Vermögenswerte und Integrationen zu verfügen. Sei hat eigene Validierungsregeln, eigene Infrastruktur und eigene Update-Mechanismen. Bridges fügen Abhängigkeiten hinzu, die gesondert bewertet werden müssen.

Die parallele Ausführung beseitigt auch nicht die Engpässe eines Contracts, der alle Schreibvorgänge bündelt. Steht der Zugang zu einem bestimmten Ökosystem im Vordergrund, können Ethereum oder seine Layer-2-Netzwerke besser geeignet sein; wird ein anderes Programmiermodell akzeptiert, bieten Solana oder Sui Alternativen, die ein Redesign und erneute Tests der Anwendung erfordern.