Technisches Resümee: Nicht alle Reads sind Konflikte: Eine Write-Only-Analyse der Sui-Blockchain

Problemstellung

Die Sui-Blockchain nutzt ein objektzentriertes Datenmodell, um eine parallele Transaktionsexekution zu ermöglichen, was theoretisch erlaubt, dass Transaktionen, die auf disjunkte Zustandsmengen zugreifen, gleichzeitig ablaufen. Die realisierte Performance ist jedoch durch die Workload-Kontention begrenzt. Vorherige empirische Analysen von Sui, wie etwa von Biton & Friedman [7], stützten sich auf ein „Read+Write“ (R+W)-Konfliktgraph-Modell, das von kontenbasierten Blockchains (z. B. Ethereum) übernommen wurde. In dem R+W-Modell besteht eine Konfliktkante zwischen zwei Transaktionen, wenn sie dasselbe Objekt aufrufen und mindestens eine davon es modifiziert.

Die Autoren argumentieren, dass das R+W-Modell fundamental nicht mit den Ausführungssemantiken von Sui vereinbar ist. Da Suis Engine nur bei mutable shared access (mutabler gemeinsamem Zugriff) serialisiert (und nicht bei shared reads), führt das R+W-Modell „spure Edges“ (falsche Kanten) ein. Ein primäres Beispiel ist die Systemuhr (Objekt 0x6): In einem R+W-Modell erzeugt jede Benutzertransaktion, die die Uhr für einen Zeitstempel liest, eine Konfliktkante mit der Systemtransaktion, die die Uhr schreibt. Dies bläht die Kontentionsmetriken künstlich auf und erzeugt „Hub-and-Spoke“-Topologien (Stern-Topologien), die schwere sequentielle Engpässe suggerieren, wo keine existieren. Folglich stellt R+W eine obere Schranke für die Kontention dar, die die sequentiellen Abhängigkeiten signifikant überschätzen und das erzielbare Parallelitätspotenzial unterschätzen kann.

Methodik

Um diese Einschränkungen zu adressieren, schlagen die Autoren ein komplementäres „Write-only“ (W-only)-Konfliktmodell vor und wenden dieses auf Sui-Mainnet-Daten bis Ende 2025 an.

Datenerfassung und -verarbeitung

• Datensatz: Transaktionsdaten wurden mittels eines benutzerdefinierten Rust/Diesel-Indexers aus Sui-Mainnet-Checkpoints gesammelt. Die Autoren sammelten deterministisch jeden 3.455sten Checkpoint (ca. 100/Tag nach dem Mysticeti-Upgrade), um einen repräsentativen Langzeitdatensatz zu erstellen.
• Graphkonstruktion: Für jeden Checkpoint wurden ungerichtete Konfliktgraphen konstruiert, wobei Knoten Transaktionen und Kanten Konflikte repräsentieren.
  • R+W-Modell: Eine Kante existiert, wenn $write(T_1) \cap (read(T_2) \cup write(T_2)) \neq \emptyset$.
  • W-only-Modell: Eine Kante existiert nur, wenn $write(T_1) \cap write(T_2) \neq \emptyset$.
• Metriken: Die Studie verwendet Standard-Graphmetriken, die aus vorangegangener Ethereum-Forschung [8, 15] adaptiert wurden:
  • Dichte (Density), Assortativität (Assortativity), Clique-Zahl (Clique Number), Größte zusammenhängende Komponente (LCC).
  • LSP/χ-Verhältnis: Das Verhältnis des längsten einfachen Pfades (LSP) zur Chromatischen Zahl (χ). Dies begrenzt die erzielbare Parallelität (LSP ist die untere Schranke sequentieller Ketten; χ ist die theoretisch minimale Anzahl an Runden).
  • Gas-gewichtete Analyse: Das Parallelitätspotenzial wird zudem durch den Gasverbrauch gewichtet, um die Rechenkosten zu berücksichtigen und zwischen vielen günstigen Transaktionen und wenigen teuren zu unterscheiden.

Analytische Techniken

1. Union-Find-Gruppierung: Objekte werden basierend auf dem gleichzeitigen Auftreten von Schreibzugriffen gruppiert, um spezifische Anwendungs-Ökosysteme (z. B. DeepBook) vom breiteren Netzwerk zu isoleniren.
2. Ökonomische Kartierung: Bestandsänderungen werden mit historischen Kursen von CoinMarketCap verknüpft, um den USD-denominierten Wert zu quantifizieren, der durch sequentielle vs. parallele Pfade fließt.
3. Kontrafaktische Proben: Die Autoren simulieren die Entfernung spezifischer Konfliktkanten (z. B. innerhalb des DeepBook-Ökosystems), um zu testen, ob bestimmte Anwendungen als inhärente Engpässe fungieren.

Zentrale Ergebnisse

1. Struktureller Topologie-Shift: Von Sternen zu Cliquen

Der Übergügang von R+W zu W-only verändert die wahrgenommene Netzwerktopologie grundlegend.

• R+W: Weist hochgradig disassortative „Hub-and-Spoke“-Strukturen auf, die durch die Systemuhr getrieben werden. Fast jede Benutzertransaktion verbindet sich mit dem Schreiber der Uhr, was einen massiven künstlichen Stern erzeugt.
• W-only: Der künstliche Stern bricht zusammen. Die verbleibende Topologie ist hochgradig assortativ und clique-dominiert. Konflikte treten in dichten, kleinen Gruppen von Transaktionen auf, die dieselben Objekte modifizieren, anstatt an einem zentralen Hub.
• Quantitativer Shift: Die mediane Grad-Assortativität springt von $-0,500$ (R+W) auf $\approx +1$ (W-only). Die mediane Clique-Zahl sinkt von 5,5 auf 4, und die größte zusammenhängende Komponente (LCC) sinkt von 8,5 auf 4.

2. Engere Grenzen für die Parallelität

Das W-only-Modell liefert eine untere Schranke für die Kontention (und damit eine engere obere Schranke für die Parallelität).

• Routine-Last: Die geschätzte optimale Parallelitäts-Headroom sinkt von $\approx 1,2\text{--}1,4\times$ (R+W) auf $\approx 1\times$ (W-only).
• Hohe Last: Die Obergrenze sinkt von $\approx 5\times$ auf $\approx 3\times$.
• Fazit: Das Entfernen der Read-seitigen Abhängigkeiten reduziert die Schätzung des optimalen Parallelitätspotenzials bei Routine-Last um 30–40 %. Der Engpass bei der Routine-Last von Sui wird als Workload-Zusammensetzung identifiziert (speziell Write-Hot-Objekte) und nicht als Unfähigkeit der parallelen Engine zur Planung.

3. Anwendungsebene-Kontention: Das DeepBook-Ökosystem

Mittels Union-Find-Gruppierung isolierten die Autoren das DeepBook-Ökosystem (Sui's natives Central Limit Order Book).

• Volumen vs. Logik: DeepBook ist für 87,3 % aller anwendungsspezifischen Konflikte nach Volumen verantwortlich. Kontrafaktische Proben (Entfernung der internen DeepBook-Kanten) zeigen jedoch, dass sein Beitrag zu sequentiellen Engpässen strikt proportional zu seinem Transaktionsvolumen ist.
• Sharding-Effekt: Im Gegensatz zu traditionellen kontenbasierten CLOBs, die die Serialisierung auf einen einzigen Smart Contract erzwingen, shardet DeepBook den Zustand über pro Pool und pro Balance-Manager existierende Objekte. Dies ermöglicht die parallele Ausführung von Transaktionen, die auf disjunkte Pools zugreifen.
• Ergebnis: DeepBook verursacht keine unverhältnismäßigen sequentiellen Engpässe im Vergleich zu anderen High-Volume-Anwendungen; seine Kontention ist eine Funktion des Volumens, nicht einer einzigartigen Logik.

4. Ökonomische Kosten der Sequentialität

Die Verknüpfung der Graphstrukturen mit dem USD-Wert offenbart die ökonomische Exposition gegenüber Ordnungseffekten.

• Sequentielle Belastung: 10–50 % des USD-denominierten Wertes des Netzwerks fließen durch sequentiell beschränkte Ausführungspfade (die LCC).
• Paralleler Fluss: Die verbleibenden 50–90 % fließen durch parallele Pfade.
• MEV-Implikationen: Der sequentielle Teil ist potenziell gegenüber Reordering-basierten MEV-Strategien (Maximal Extractable Value) exponiert, während der parallele Teil dies nicht ist. Die Autoren merken an, dass dies eine Momentaufnahme der aktuellen Workload-Exposition ist, kein universelles Limit.

Bedeutung und Behauptungen

Das Paper beansprucht, eine semantische Neubewertung der Konfliktmodellierung in Sui geliefert zu haben. Durch die Abstimmung des Konfliktmodells auf die tatsächlichen Ausführungssemantiken von Sui (Serialisierung von mutable shared objects) eliminiert das W-only-Modell die durch Read-only-Zugriffe induzierten „Nicht-Ausführungs-Abhängigkeiten“.

• Methodischer Beitrag: Die Autoren schlagen das W-only-Modell als notwendige Ergänzung zu R+W vor und argumentieren, dass R+W die Kontention in objektzentrierten Systemen systematisch überschätzt.
• Architektonische Erkenntnis: Die Studie zeigt, dass das Objektmodell von Sui erfolgreich verhindert, dass ein, was in kontenbasierten Chains ein sequentieller Engpass wäre (ein CLOB), in ein Szenario umwandelt, in dem die Kontention mit dem Volumen skaliert, aber nicht mit inhärenten logischen Beschränkungen.
• Praktische Auswirkungen: Die Ergebnisse legen nahe, dass Betreiber ihre Infrastruktur eher auf das „Tail-Behavior“ (extremes Verhalten, wie das virale Ereignis des Sui 8192 Spiels, das eine $\approx 175\times$ Beschleunigung zeigte) ausrichten sollten, statt auf das Durchschnittsverhalten, da die Routine-Last oft wenig residuale Parallelität zur Ausnutzung bietet, die durch die Workload-Zusammensetzung begrenzt wird.

Die Autoren kommen zu dem Schluss, dass die W-only-Methodik eine plattformübergreifende Terminologie bietet, um die anwendungstreibende Kontention moderner Blockchains (z. B. Aptos, Solana) zu vergleichen, ohne den „Read-side Noise“, der die analysen kontenzentrierter Systeme dominiert.