In der allgemeinen Denkweise glauben die Menschen, dass die Systemleistung einfach erhöht werden kann, indem man mehr CPU-Kerne hinzufügt oder leistungsstärkere Server aufrüstet. Das ist bei einigen unabhängigen Berechnungsvorgängen richtig, aber wenn es um Blockchain geht, ist die Realität viel komplexer

Doch was ist die Wahrheit? Altius wird dieses Problem klären

Wenn die Speicherebene nicht mithalten kann, macht zusätzliche Rechenleistung keinen Sinn

Blockchain führt nicht nur Berechnungen (Compute) aus, sondern liest auch kontinuierlich den Status (state I/O) ein/aus. Jede Transaktion ist nicht nur einige Additionen/Subtraktionen, sondern erfordert auch die Aktualisierung von Daten im Trie, der Schlüssel-Wert-Datenbank und die Synchronisierung mit anderen Knoten.

Dies schafft einen Flaschenhals: Wenn der Speicher nicht schnell genug ist oder nicht parallelisiert werden kann, wird der hinzugefügte CPU warten müssen, um Daten zu erhalten, anstatt zu verarbeiten.

Warum das Gleichgewicht zwischen Compute und Storage der Schlüssel ist

  • Flaschenhalsverschiebung. Wenn der Kern erhöht wird, kann der Compute-Durchsatz steigen, aber die I/O-Zeit (Festplatte, Datenbank, Trie-Updates) nimmt den Großteil in Anspruch, wodurch der marginale Nutzen nahezu 0 wird.

  • Die lineare Leistung tritt nur auf, wenn die Komponenten gleichmäßig steigen. Wenn die Speicherkapazität nicht erweitert wird, wird das System CPU-reich – I/O-arm.

  • Spezifische Blockchain: Jede Transaktion muss Determinismus und Konsistenz gewährleisten, daher sind das Schreiben/Lesen des Status häufig Hardware, die viele Male wiederholt wird, und kann nicht übersprungen werden.

Illustration aus der heutigen Blockchain

1. Ethereum-Clients und die Grenzen von LevelDB/RocksDB

Beliebte Clients wie Geth oder Reth verwenden häufig LevelDB oder RocksDB zur Verwaltung des Status. Dies sind allgemeine Schlüssel-Wert-Datenbanken, die nicht speziell für Blockchain optimiert sind.

Ergebnis: Selbst wenn Sie die Anzahl der CPU-Kerne verdoppeln, steigt die Transaktionsverarbeitung nicht erheblich, da der Großteil der Zeit mit I/O-Operationen bei der Datenbank verbraucht wird.

Beispiel: In einigen Experimenten stammen mehr als 60 - 70 % der Latenz in der Transaktionsverarbeitung vom Lesen/Schreiben von Statusdaten, nicht vom Compute.

2. Rollup: schöne Benchmarks, in der Realität schwach

Viele Rollup-Projekte geben beeindruckende TPS-Zahlen in Tests an, die nur Berechnungen messen - d.h. nur die Logik des Vertrags testen, ohne den vollständigen Storage auszuführen.

Wenn jedoch in der Praxis mit einem Statusdatenbank implementiert wird, sinkt die TPS stark, manchmal auf ein Zehntel.

Beispiel zum Vorstellen: Ein Rollup kann im Labor 50k TPS erreichen, aber bei der Verarbeitung von Transaktionen mit dem gesamten State-Trie sinkt es auf 5k - 7k TPS. Der Grund? Der Speicher ist nicht schnell genug, um die riesigen Datenmengen in Echtzeit zu aktualisieren.

3. Mächtiger Server, aber niedrige Effizienz

Einige Blockchains haben versucht, auf extrem leistungsstarken Servern zu laufen - CPU mit 128 Kernen, TB RAM, teure SSDs. Aber die tatsächliche Leistung verbessert sich kaum.

Das Problem ist: Die Datenbank funktioniert weiterhin nach der sequentiellen Architektur oder wird durch Sperren eingeschränkt, sodass die I/O-Bandbreite sich nicht entsprechend den Hardware-Ressourcen erweitert.

Ergebnis: Die Infrastrukturkosten steigen stark, aber TPS verbessert sich nur wenig. Dies ist ein lebendiger Beweis dafür, dass viele Kerne nicht gleich viel Geschwindigkeit in der Blockchain bedeuten.

Der richtige Ansatz: Skalierung = Compute + synchroner Storage

  • Parallelisierung der Ausführung auf Befehlsebene (Instruction-level Parallelism, SSA).

  • Speichermotor, der für die Blockchain-Workloads optimiert ist (SSMT, sharded state, intelligentes Caching).

  • Optimistische Parallelitätskontrolle entscheidet sich dafür, anstatt zufällig zurückzusetzen, Verschwendung zu reduzieren.

  • Entwickler ermutigen, parallel-freundlichen Code zu schreiben, um die Infrastruktur zu nutzen.

Fazit

Mehr Kerne sind keine Wunderlösung. Die Leistung der Blockchain hängt vom Gleichgewicht zwischen Berechnung und Speicherung ab.

Eine richtige Architektur muss den I/O-Flaschenhals parallel zum Compute behandeln und zusätzliche Leistung in reale Leistung umwandeln. Das ist der Grund, warum Plattformen wie Altius sich auf beide Fronten konzentrieren: Parallelisierung von Compute und Erweiterung des Speichers, um reale Leistung zu erzielen, nicht nur schöne Benchmarks.