Was ist WebAssembly (WASM) und warum wollen Ethereum und Solana es für ihre Smart Contracts?

In den letzten Jahren drehte sich die Debatte um die Skalierbarkeit von Blockchains vor allem um zusätzliche Schichten, Netzwerk-Sharding und Änderungen des Konsensmechanismus. Ein wichtiger Aspekt, der jedoch weniger Beachtung findet und genauso entscheidend sein könnte wie jedes Protokoll-Update, ist die virtuelle Maschine, die Smart Contracts ausführt. Diese für die meisten Nutzer unsichtbare Schicht bestimmt die Transaktionskosten (Gas), die Ausführungszeit und die Art der Logik, die Entwickler implementieren können. Hier kommt WebAssembly ins Spiel.

Dieser Artikel erklärt, was WebAssembly (WASM) ist, wie es technisch funktioniert, ohne dass man sich in den Code vertiefen muss, und warum Projekte wie Ethereum und Solana sich seit einiger Zeit auf diese Technologie konzentrieren, um die Ausführungs-Engine ihrer Smart Contracts neu zu gestalten. Wenn Sie bereits mit dem Blockchain-Ökosystem vertraut sind und verstehen möchten, wohin sich die zugrunde liegende Infrastruktur entwickelt, sind Sie hier genau richtig.

Was ist WebAssembly und woher stammt es?

WebAssembly, abgekürzt WASM, ist ein binäres Befehlsformat, das für die Ausführung auf einer Stackmaschine entwickelt wurde. Es entstand ursprünglich als offener Webstandard und wurde vom World Wide Web Consortium (W3C) in Zusammenarbeit mit Mozilla, Google, Microsoft und Apple entwickelt. Im Dezember 2019 erhielt es den Status einer offiziellen Empfehlung.

Die Idee hinter WASM ist einfach, aber wirkungsvoll: ein portables Kompilierungsziel für Hochsprachen wie C, C++, Rust oder Go bereitzustellen, sodass der resultierende Code auf jeder Plattform nahezu nativ schnell ausgeführt werden kann, unabhängig von der zugrunde liegenden Prozessorarchitektur. Im Webbereich ermöglichte dies rechenintensive Anwendungen – Videoeditoren, Game-Engines, Design-Tools – direkt im Browser mit einer vor zehn Jahren noch unvorstellbaren Performance.

Was WASM für Blockchain besonders interessant macht, ist nicht sein Ursprung im Web, sondern seine grundlegenden Eigenschaften: Es ist deterministisch (die gleiche Eingabe erzeugt immer die gleiche Ausgabe), von Grund auf sicher (es läuft in einer Sandbox-Umgebung ohne Zugriff auf das zugrundeliegende Betriebssystem), speichereffizient (die Binärdateien sind kompakt) und portabel (es funktioniert in jeder Umgebung, die die WASM-Laufzeitumgebung implementiert). Diese vier Eigenschaften sind genau das, was ein Blockchain-Netzwerk von seiner Laufzeitschicht benötigt.

Wie funktioniert WASM: das Ausführungsmodell?

Um zu verstehen, warum WASM im Kontext von Smart Contracts wichtig ist, ist es hilfreich, ein klares Verständnis davon zu haben, wie es auf einer höheren Ebene funktioniert.

Ein in Rust geschriebenes Programm wird beispielsweise in eine .wasm-Datei kompiliert, die Anweisungen im Binärformat enthält, die kein realer Prozessor direkt versteht. Ausgeführt wird diese Datei von einer WASM-Laufzeitumgebung – einem Just-in-Time-Interpreter (JIT) bzw. -Compiler –, der die Anweisungen zur Laufzeit in den nativen Code der Hardware übersetzt. Dieser zweischichtige Ansatz – portabler Code und lokale Laufzeitumgebung – verleiht WASM seine Kombination aus Portabilität und Geschwindigkeit.

Es gibt drei Ausführungsmodelle für eine WASM-Laufzeitumgebung:

1. Interpretation: Die Laufzeitumgebung liest und führt die Anweisungen nacheinander aus. Dies ist das langsamste, aber auch das am einfachsten zu implementierende Modell.
   AOT-Kompilierung (Ahead-of-Time): WASM-Code wird vor der Ausführung in nativen Code kompiliert. Maximale Leistung, jedoch eingeschränkte Portabilität.
2. Just-in-Time-Kompilierung (JIT): Die Laufzeitumgebung kompiliert WASM-Fragmente während der Ausführung in nativen Code. Dies ist der von den meisten modernen Browsern genutzte Kompromiss zwischen Geschwindigkeit und Flexibilität.

In der Blockchain ist Determinismus von entscheidender Bedeutung: Alle Knoten im Netzwerk müssen bei der Ausführung desselben Smart Contracts exakt zum selben Ergebnis gelangen. Dies schließt aggressive Optimierungen von Just-in-Time-Laufzeitumgebungen (JIT) aus, die je nach Hardware leicht unterschiedliche Ergebnisse liefern können. Blockchain-Projekte, die WASM einsetzen, müssen dieses Problem mit speziell für deterministisches Verhalten entwickelten Laufzeitumgebungen lösen. wasmtime o Wässer.

Warum weist das aktuelle EVM Einschränkungen auf, die WASM behebt?

Die Ethereum Virtual Machine (EVM) wurde 2015 mit den damals verfügbaren Ressourcen und Kenntnissen entwickelt. Sie war außerordentlich erfolgreich: Heute werden Milliarden von Dollar an digitalen Vermögenswerten über Smart Contracts transferiert, die in Solidity geschrieben und für die EVM kompiliert wurden. Doch mit dem Wachstum des Ökosystems werden ihre strukturellen Grenzen immer deutlicher.

Die Ethereum Virtual Machine (EVM) ist eine 256-Bit-Stackmaschine. Diese Designentscheidung ermöglicht gängige kryptografische Operationen in Ethereum (wie etwa modulare Arithmetik für elliptische Kurven), erschwert aber generische Operationen, die jedes moderne Programm benötigt. Da die aktuelle Hardware mit 64-Bit-Registern arbeitet, muss die EVM 256-Bit-Operationen mithilfe mehrerer 64-Bit-Befehle simulieren, was einen erheblichen Mehraufwand verursacht.

Darüber hinaus ist der Befehlssatz der EVM (ihre ISA, Befehlssatzarchitektur) relativ klein und geschlossen. Das Hinzufügen neuer Befehle erfordert die Durchführung des Governance-Prozesses von Ethereum, der Jahre dauern kann. Im Gegensatz dazu verfügt WASM über einen modernen und erweiterbaren Befehlssatz dank standardisierter Vorschläge und profitiert von jahrelangen Investitionen von Mozilla, Google und anderen Akteuren in die Optimierung seiner Laufzeitumgebungen.

Die Leistungsunterschiede sind erheblich. Benchmarks des Teams von Parity Technologies (Entwickler von Substrate, dem Polkadot-Framework) zeigten, dass die Vertragsausführung auf WASM bei rechenintensiven Operationen 10- bis 30-mal schneller sein kann als auf der EVM. Da die Transaktionskosten (Gas) direkt von der Rechenzeit abhängen, führt dies zu niedrigeren Gebühren für die Nutzer.

Ethereums Wette: EVM-Objektformat und der Weg zu WASM

Ethereum wird die EVM nicht über Nacht ersetzen. Rückwärtskompatibilität ist eines der wichtigsten Prinzipien des Ökosystems: Tausende von implementierten Smart Contracts, Milliarden an gebundenen Vermögenswerten und jahrzehntelang auf Solidity basierende Tools bedeuten, dass jede Migration schrittweise und sorgfältig erfolgen muss.

Der von den Protokollentwicklern gewählte Weg umfasst zwei Phasen. Die erste ist die Annahme von EVM-Objektformat (EOF)EOF ist eine strukturelle Überarbeitung des EVM-Bytecode-Formats, die es sicherer, zur Einsatzzeit überprüfbar und für Kunden optimierbar macht. EOF ist nicht WASM, teilt aber dessen Philosophie: die klare Trennung von Code und Daten, die Schaffung einer Struktur, die von Toolchains statisch analysiert werden kann, und die Beseitigung problematischer, vom ursprünglichen Design übernommener Muster.

Die zweite, längerfristige Phase beinhaltet einen echten Übergang zu einer WASM-basierten Laufzeitumgebung oder einer davon inspirierten. Das Projekt eWASM Das Ethereum WebAssembly (eWASM)-Projekt untersuchte jahrelang, wie die EVM durch eine deterministische WASM-Laufzeitumgebung ersetzt werden kann. Obwohl eWASM als konkretes Projekt in umfassendere Initiativen integriert wurde, wird die Forschung in diese Richtung innerhalb der Ethereum Foundation weiterhin aktiv fortgeführt.

Vitalik Buterin und andere Forscher haben Vorschläge veröffentlicht, die ein Hybridmodell untersuchen, in dem Verträge der nächsten Generation in einer WASM-Umgebung ausgeführt werden können, während die Kompatibilität mit bestehenden EVM-Verträgen durch eine Übersetzungsschicht oder ein Koexistenzmodell erhalten bleibt. Das Update Pectra Der Plan für 2025 schloss WASM nicht direkt ein, setzte aber die Arbeit von EOF fort, die den Boden für diesen zukünftigen Übergang bereitet.

Solana und sBPF: die Variante, die sich bereits in Produktion befindet

Solana verfolgte einen anderen Ansatz als ursprünglich geplant. Anstelle der EVM wählte es eine Laufzeitumgebung, die auf … basierte. BPF (Berkeley Paketfilter), eine Technologie, die ursprünglich für die Netzwerkpaketfilterung im Linux-Kernel entwickelt wurde. Darauf aufbauend entwickelten sie sBPF (Solana BPF), eine Variante, die an die Bedürfnisse eines Hochgeschwindigkeits-Blockchain-Netzwerks angepasst ist.

sBPF teilt die gleiche Grundphilosophie wie WASM: Es ist ein niedrigstufiges, deterministisches und portables Befehlsformat, das aus Hochsprachen wie Rust kompiliert werden kann. Solana-Verträge (genannt sBPF) Programme(Nicht Smart Contracts im Sinne der Protokollnomenklatur) werden zu sBPF kompiliert und in einer Laufzeitumgebung namens ausgeführt. Meereshöhe, wodurch die parallele Ausführung mehrerer zustandsloser Transaktionen ermöglicht wird.

In den Jahren 2024 und 2025 kündigte das Solana Labs-Team die Migration von sBPF auf eine neue Version an und begann mit deren Umsetzung. sBPFv2Dieses Update beinhaltet zusätzliche Anweisungen, Verbesserungen am Speichermodell und eine höhere Kompilierungseffizienz. Diese Weiterentwicklung folgt dem gleichen Ansatz wie der Vorschlag von eWASM für Ethereum: die Modernisierung der Ausführungsschicht, um komplexere Smart Contracts bei geringerem Rechenaufwand zu unterstützen.

Wichtiger noch: Im Solana-Ökosystem wurden auch Experimente mit reinen WASM-Laufzeitumgebungen im Rahmen von Projekten wie beispielsweise Neon-EVM (wodurch EVM-Verträge auf Solana ausgeführt werden können) und die Erforschung anderer Vertragsprogrammiersprachen. Die Konvergenz hin zu modernen Ausführungsstandards, sei es WASM oder davon inspirierte Formate, ist ein klarer Trend auf der gesamten ersten Ebene der Branche.

Aktueller Status: WASM auf der Blockchain (Stand: Juni 2026)

Das Blockchain-Ökosystem hat WASM noch nicht einheitlich übernommen, aber der Trend ist eindeutig. Mehrere Projekte setzen es bereits produktiv ein.

• Polkadot / Substrat Es ist vermutlich das Ökosystem, in dem WASM am weitesten verbreitet ist. Alle Verträge in substratbasierten Lieferketten, einschließlich Paletten- und Modulverträgen. PalettenverträgeSie laufen auf einer WASM-Laufzeitumgebung. Die Wahl war nicht experimentell: Sie wird seit Jahren produktiv mit Astar Network, Moonbeam und anderen Parachains eingesetzt.
• Kosmos und sein Rahmen KosmWasm Sie ermöglichen die Bereitstellung von in Rust geschriebenen und zu WASM kompilierten Smart Contracts auf jeder Blockchain des Cosmos-Ökosystems, einschließlich Ketten wie Osmosis, Sei und Injective. CosmWasm hat sich zu einer der aktivsten Smart-Contract-Umgebungen außerhalb des EVM-Ökosystems entwickelt, gerade weil es die Sicherheits- und Leistungsgarantien von WASM bietet.
• NEAR-Protokoll Es nutzte von Anfang an WASM als primäre Laufzeitumgebung und ermöglicht das Schreiben von Verträgen in Rust oder JavaScript (kompiliert zu WASM). Sein paralleles Ausführungsmodell (Sharding) profitiert insbesondere von der Recheneffizienz von WASM.

Bezüglich Ethereum behält die Roadmap nach Pectra EOF als unmittelbare Priorität und WASM als aktiven Forschungsschwerpunkt für mittel- bis langfristige Zeiträume bei. Die Koexistenz von EVM und einer zukünftigen WASM-Umgebung erscheint laut aktuellen Diskussionen im Ethereum-Forschungsforum als das wahrscheinlichste Szenario.ethresear.ch).

Was bedeutet das für Entwickler von Smart Contracts?

Die praktische Frage für einen Entwickler, der heute mit Smart Contracts arbeitet, ist, ob er etwas an seinem Arbeitsablauf oder an dem von ihm gewählten Technologie-Stack ändern sollte.

Kurzfristig lautet die Antwort für die meisten Ethereum-Entwickler nein. Solidity ist nach wie vor die am weitesten verbreitete Programmiersprache, ihre Tools sind am ausgereiftesten, und auf der EVM bereitgestellte Smart Contracts funktionieren weiterhin. Das EOF-Upgrade wird, sobald es das Mainnet erreicht, für die meisten Projekte transparent sein.

Mittelfristig wird das Erlernen von Rust jedoch zu einer strategischen Investition für jeden Smart-Contract-Entwickler. Rust ist die bevorzugte Sprache für die Entwicklung von Smart Contracts in Substrate, CosmWasm, Solana und NEAR – allesamt Produktionsumgebungen mit Milliarden von Dollar an gebundenen Vermögenswerten. Sollte Ethereum ebenfalls eine Umgebung schaffen, in der Rust zu einer kompatiblen Laufzeitumgebung kompiliert werden kann, amortisiert sich der Lernaufwand in mehreren Ökosystemen.

Aus Sicht der Endnutzer von Blockchain-Plattformen sollte der Übergang zu WASM reibungslos verlaufen: günstigere Transaktionen, komplexere Verträge (wodurch die Möglichkeiten dezentraler Anwendungen erweitert werden) und höhere Sicherheit auf der Laufzeitebene. Die Effizienz der unsichtbaren Engine bestimmt das wahrgenommene Nutzererlebnis.

Über die reine Leistung hinaus: WASM als Infrastruktur der digitalen Zukunft

Die Geschichte von WebAssembly auf der Blockchain ist im Kern die Geschichte, wie dezentrale Netzwerke zu praxistauglichen Computerplattformen heranreifen. Jahrelang drehte sich der Diskurs um die Blockchain vor allem um digitale Vermögenswerte und die Dezentralisierung des Finanzwesens. Das ist nach wie vor zentral, doch die Infrastruktur, die diese Wirtschaft stützt, entwickelt sich immer mehr zu etwas, das eher einem verteilten Betriebssystem als einem erweiterten Hauptbuch ähnelt.

WASM verkörpert diese Entwicklung. Es handelt sich nicht nur um eine technische Optimierung, sondern auch um ein Zeichen dafür, dass Ethereum, Solana und das gesamte Ökosystem die allgemeine Codeausführung in dezentralen Umgebungen ernst nehmen. Wenn eine Technologie, die ursprünglich zur Beschleunigung von Webbrowsern entwickelt wurde, sich als Schlüsselkomponente der nächsten Generation von Smart Contracts erweist, ist der gemeinsame Nenner unübersehbar: Tragbares, effizientes und sicheres Computing ist die knappe Ressource, die jede digitale Infrastruktur zu optimieren versucht.

Die Frage ist nicht, ob WASM die Ausführung von Smart Contracts auf Mainframes dominieren wird. Die Frage ist vielmehr, wie schnell, mit welchem ​​Übergangsmodell und welche Ökosysteme diese Migration vorantreiben werden. Sicher ist bereits, dass die Engine, die Smart Contracts der Zukunft ausführt, viel eher einer modernen WASM-Laufzeitumgebung ähneln wird als der 256-Bit-Stack-Maschine von 2015.

Häufig gestellte Fragen zu WebAssembly und Smart Contracts