Blockchain-Protokolle verwenden häufig eine deterministische Zählung von Instruktionen – sogenannte „Steps“ – um DoS-Schutz und Block-Limit-Budgets zu definieren. Neuere Messungen zeigen jedoch, dass identische Schrittzahlen je nach Host-Mikroarchitektur, Cache-Lokalität oder Ausführungsengine bis zu 23-mal unterschiedliche Wall-Clock-Laufzeiten erzeugen können. Diese Diskrepanz gefährdet die Sicherheit von Protokollen, weil Angreifer Knoten asymmetrisch auslasten können, wenn die reale Ausführungszeit nicht mehr durch das Schritt-Budget gedeckt ist.

Deterministische Schrittzählung in Blockchain-Virtual-Machines

In vielen virtuellen Maschinen (VMs) wird das Ausführungsbudget in Steps angegeben, wobei ein Step einer RV32IM-Instruktion im Interpreter entspricht. Dieser Zähler ist unabhängig von der tatsächlichen CPU-Instruktion des Hosts und spiegelt nur die Menge an ausgeführten Opcodes wider. Die Annahme, dass ein fester Step-Preis die physische Laufzeit zuverlässig abbildet, wird durch aktuelle Experimente widerlegt.

Messungen: 23-fache Laufzeitdifferenz bei identischer Schrittzahl

Ein deterministischer RISC-V-Interpreter wurde auf zwei unterschiedlichen Plattformen getestet:

• Motorola Edge 40 Neo (MediaTek MT6879V/ZA, 2 × 2,5 GHz + 6 × 2,0 GHz, Android 15)
• Intel Core i5-9400 (6 Kerne, 2,90 GHz, Windows 11)

Bei einem festen Obergrenzenwert von 7 000 000 Steps zeigte das pointer-chasing -Mix (96 Pages) eine Laufzeit von 619 ms, während das ML-DSA-44 -Mix nur 26 ms benötigte – ein Faktor von etwa 23, obwohl beide exakt dieselbe Schrittzahl lieferten.

Weitere Messungen verdeutlichen, dass das gleiche Opcode-Set bei sequenziellem Zugriff (186,3 M Steps/s) fast doppelt so schnell ist wie beim pointer-chasing (82,1 M Steps/s). Der Unterschied entsteht ausschließlich durch das Speicherzugriffsmuster, nicht durch die Opcode-Identität.

Warum die Opcode-Identität allein nicht ausreicht

Ein statisches Gewicht pro Opcode kann die beobachteten Unterschiede nicht erklären. Der entscheidende Faktor ist das Working Set – die Anzahl der berührten 4 KiB-Seiten während der Ausführung. Die Messungen zeigen:

• 16 KiB (4 Pages) – 163,6 M Steps/s
• 64 KiB (16 Pages) – 125,5 M Steps/s
• 384 KiB (96 Pages) – 80,8 M Steps/s
• 4 MiB (1024 Pages) – 10,9 M Steps/s (starker Abfall)

Der Abfall korreliert mit dem Überschreiten von L1- bzw. L2-Cache-Grenzen und verdeutlicht, dass die physische Speicherhierarchie die Laufzeit dominiert, nicht die reine Instruktionszahl.

Historische Parallelen: EVM, EIP-2929 und quadratische Speicherexpansion

Ethereum hat bereits 2016 massive DoS-Angriffe erlebt, bei denen Speicher- und Disk-Zugriffe (z. B. EXTCODESIZE ) stark unterbepreist waren. Die Einführung von EIP-2929 unterschied zwischen „cold“ (2 100 Gas) und „warm“ (100 Gas) State-Accesses – ein Preis-Sprung von Faktor 21. Dieser Mechanismus dämpft Cache-Effekte im globalen Zustandsspeicher.

Für den flüchtigen Arbeitsspeicher innerhalb der VM existiert jedoch kein vergleichbares Caching-Modell. Die EVM-Formel zur Speicher-Gas-Berechnung (3 Words + Words²/512, 2015) bepreist lediglich die maximale Adressausdehnung quadratisch, nicht die Verteilung der Zugriffe. Dadurch werden „Sparse Memory Accesses“ innerhalb reservierter Rahmen nicht angemessen bestraft.

Moderne Ansätze: PolkaVM, CKB-VM und JIT-Optimierungen

Projekte wie Polkadot (PolkaVM/PVM) und Nervos (CKB-VM) setzen auf RISC-V für Smart-Contracts. PolkaVM verwendet eine Single-Pass-Rekompilierung (AOT/JIT) anstelle eines reinen Interpreters, um Dispatch- und Cache-Overheads zu reduzieren. Benchmarks aus 2024 zeigen, dass ein proprietäres RISC-V-JIT im Vergleich zu spezialisierten Wasm-Engines (z. B. Wasmer) einen Overhead-Faktor von 2,5 × aufweist – ein Hinweis darauf, dass JIT-Kompilierung zwar Dispatch-Kosten eliminiert, aber die Latenz-Lücke zwischen L1-Cache und DRAM (≈ 1 : 100 Zyklen) weiterhin besteht.

Ein weiteres Experiment vergleicht die kryptografischen Primitive ML-DSA-44 (lattice-basiert) und SLH-DSA-128s (hash-basiert) in drei Ausführungsmodi (Interpreter, JIT, native). Die Ergebnisse:

• ML-DSA-44 – Interpreter 28,3 ×, JIT 3,8 ×
• SLH-DSA-128s – Interpreter 8,0 ×, JIT 0,9 × (leicht schneller als native)

Der JIT kann bei SHA-2-intensiven Workloads (hash-basiert) fast native Geschwindigkeit erreichen, während lattice-intensive Workloads stärker von Cache-Effekten betroffen sind.

Gegenmaßnahmen: Touched-Pages-Tracking und Single-Pass-JITs

Ein möglicher Ansatz besteht darin, tatsächlich berührte Seiten („Touched Pages“) zu zählen. Dies erfordert ein Tracking auf VM-Ebene, erhöht jedoch den Overhead pro Memory-Load/Store. Single-Pass-JITs eliminieren Interpreter-Dispatch, lösen aber das Grundproblem der Cache-Miss-Lücken nicht vollständig, weil die physische Latenz zwischen L1-Cache und DRAM unverändert bleibt.

FAQ

• Gibt es bereits Blockchain-Systeme, die Zugriffsmuster statt nur Allokation bepreisen? Ethereum implementiert das Konzept für den globalen Zustandsspeicher mit EIP-2929 (Cold/Warm-Slots). Für den flüchtigen RAM wird bislang nur die maximale Adressausdehnung bepreist, nicht die Cache-Lokalität.
• Warum war der JIT bei SLH-DSA-128s schneller als nativer Code? Cranelift-ähnliche JITs können Schleifen und Inlining basierend auf zur Laufzeit bekannten Größen stark optimieren, während native Builds ohne Profil-Guided-Optimierung (PGO) konservativere Vektorisierungen wählen.

Fazit

Die vorgestellten Messungen belegen eindeutig, dass eine reine Schritt-Zählung in RISC-V- und WASM-Interpretern die reale Ausführungszeit nicht zuverlässig abbildet. Speicher-Zugriffsmuster, Working-Set-Größe und die zugrunde liegende Mikroarchitektur können die Laufzeit um das 20—23-fache variieren. Historische Lösungen wie EIP-2929 zeigen, dass ein „Cold vs. Warm“-Ansatz ein bewährtes Muster zur Dämpfung von Cache-Effekten ist. Moderne RISC-V-basierte VMs (PolkaVM, CKB-VM) versuchen, durch JIT-Rekompilierung Dispatch-Kosten zu reduzieren, können jedoch die fundamentale Latenz zwischen Cache und DRAM nicht eliminieren. Für sichere Protokoll-Budgets ist daher ein erweitertes Metrik-Modell nötig, das neben Opcode-Schritten auch berührte Speicher-Pages oder Cache-Lokalisierung berücksichtigt.