Das Zero-Syscall-Netzwerk: Implementierung von WASM-zu-WASM-Tunneling für Nano-Services
Das Zero-Syscall-Netzwerk: Implementierung von WASM-zu-WASM-Tunneling für Nano-Services
Warum sich vom Kernel ausbremsen lassen? Dieser Beitrag zeigt, wie man co-lokalisierte WASM-Komponenten mit einem direkten, speicherabbildenden Tunnel verbindet, der das OS-Netzwerk-Stack vollständig umgeht — und wo dieses Ziel im Jahr 2026 in der Praxis steht.
1. Einführung: WebAssembly jenseits des Browsers
Die Geschichte von WebAssembly im Jahr 2026 ist eine von echten, messbaren Fortschritten neben hartnäckigen, ungelösten Lücken. Auf der Browser-Seite ist die Lage eindeutig positiv. Laut Chrome Platform Status wird WebAssembly Anfang 2026 in etwa 5,5 % der Chrome-Seitenladevorgänge genutzt, gegenüber 4,5 % im Vorjahr. Figma, Adobe Photoshop im Web, AutoCAD Web und Google Meet’s Video-Pipeline laufen heute alle auf WASM. Die WebAssembly 3.0-Spezifikation wurde im September 2025 zum W3C-Standard, inklusive Garbage Collection, 64-Bit-Speicheradressierung, Tail-Call-Optimierung und strukturierter Ausnahmebehandlung.
Außerhalb des Browsers ist das Bild differenzierter. Edge-Plattformen, die auf WASM aufbauen, bewältigen ernsthaften Produktionsverkehr: Fermyon’s Edge-Netzwerk verarbeitet rund 75 Millionen Anfragen pro Sekunde, Fastly Compute@Edge hat mehr als 10.000 Nutzer, und Cloudflare Workers — die auf einem V8-Isolat-Modell laufen, das eng mit WASM-Sandboxing verbunden ist — operieren seit Februar 2026 von über 330 Points of Presence weltweit, mit Llama 3.1 und 3.2 Modellen für Inferenz am Edge.
Was diese Deployments gemeinsam haben, ist ein spezifisches Profil: sie sind zustandslos, kurzlebig und in ihren I/O-Anforderungen begrenzt. Sobald zwei co-lokalisierte WASM-Komponenten Daten mit hoher Frequenz austauschen müssen, stoßen sie auf das gleiche Flaschenhalsproblem: das host OS-Netzwerk-Stack. Dieser Artikel beschäftigt sich damit, diesen Flaschenhals direkt anzugehen.
2. Der Kernel-Zuschlag: Warum Loopback für Nano-Services zu langsam ist
Wenn zwei co-lokalisierte WASM-Komponenten über einen traditionellen Loopback-Socket kommunizieren, nimmt der Datenpfad folgende Route:
- Serialisierung. Die sendende Komponente kodiert ihre Nutzlast — typischerweise in JSON, MessagePack oder Protocol Buffers — und schreibt sie in einen Puffer im linearen Speicher.
- Host-Aufruf und Kontextwechsel. Die WASM-Laufzeit führt einen Host-Import aus (bei WASI 0.2 läuft das über
wasi-sockets), der in den Kernel mittels eines Syscalls wiesendmsgtrappt. - Kernel-Durchlauf. Der Kernel reserviert Socket-SKBs, schiebt das Paket durch den vollständigen TCP/IP-Stack, wendet eventuell
iptables- odereBPF-Regeln an und routet es zum Loopback-Interface (lo). - Zweiter Kontextwechsel. Der Kernel weckt die empfangende Laufzeit.
- Kopieren und Deserialisierung. Die empfangende Komponente kopiert Daten aus dem Kernel-Speicher in ihren eigenen linearen Speicher und deserialisiert.
Für Microservices, die Datenbank-Roundtrips in Zehntelsekunden oder Hundertstelsekunden messen, ist dieser Overhead vernachlässigbar. Für Nano-Services, die Aufgaben wie Echtzeit-Bid-Bewertung, Tensor-Vorverarbeitung vor einem Inferenzaufruf oder Hochfrequenz-Marktdaten-Normalisierung erledigen, kann eine Loopback-Runde in wenigen Millisekunden mehr CPU-Zyklen verbrauchen als die eigentliche Geschäftslogik.
Das Ziel eines Zero-Syscall-Netzwerks ist es, Schritte 2 bis 4 für co-lokalisierte Komponenten zu eliminieren und die intra-Knoten-Kommunikation auf die Geschwindigkeit eines Speicherzugriffs zu reduzieren.
3. Wo der WASM-Standard im Jahr 2026 tatsächlich steht
Bevor wir in die Umsetzung einsteigen, lohnt es sich, den aktuellen Stand der relevanten Spezifikationen präzise zu betrachten, da online viel Verwirrung besteht zwischen dem, was aspirativ ist, und dem, was tatsächlich ausgeliefert wird.
WASI 0.2 wurde im Januar 2024 veröffentlicht und ist die derzeit stabile Version. Sie integriert das Component Model und liefert eine Reihe definierter “Welten” wie wasi-cli, wasi-http, wasi-sockets, wasi-filesystem, wasi-clocks und wasi-io. Wasmtime ist die vollständigste Laufzeitimplementierung; es hat den Core Project-Status der Bytecode Alliance erreicht und verfolgt eine langfristige Sicherheitsunterstützung.
WASI 0.3 (WASIp3) ist die Version, die native asynchrone Unterstützung einführt — future- und stream-Typen auf ABI-Ebene, kombinierbare Nebenläufigkeit über Komponenten in verschiedenen Sprachen und Zero-Copy-Streaming-Primitives. Diese Version ist die Grundlage für die im Artikel beschriebenen Zero-Syscall-Netzwerk-Pattern. Der erste Release-Candidate wurde im November 2025 in Spin v3.5 integriert. Wasmtime 37.0.0 lieferte experimentellen, optionalen WASIp3-Support mit native asynchroner I/O, das vollständige Spezifikations-Release bleibt jedoch im Release-Candidate-Status — API-Namen könnten sich noch ändern. WASI 1.0, das langfristige Stabilitätsgarantien bringen soll, ist für Ende 2026 oder Anfang 2027 geplant.
WebAssembly 3.0 wurde im September 2025 zum W3C-Standard, inklusive neun Produktionsfeatures wie WasmGC und 128-Bit-SIMD.
Das Component Model — das die “LEGO-Baustein”-Zusammensetzung von WASM-Modulen aus verschiedenen Sprachen durch WIT (WebAssembly Interface Types)-Schnittstellen beschreibt — befindet sich in den W3C-Phasen der Spezifikation, voraussichtlich parallel oder nach den Releases von WASI 0.3 oder 1.0.
Praktisch bedeutet das: die Patterns in diesem Artikel basieren auf realer, ausgelieferter Software (Wasmtime, Spin, WasmEdge), aber einige der mächtigsten Primitive — insbesondere das Hochleistungs-Streaming und die kombinierbare Async-Programmierung — sind noch in der Stabilisierung.
4. Das Component Model und das Lift/Lower-Paradigma
Die Grundlage für Zero-Syscall-Kommunikation zwischen WASM-Komponenten ist der Lift/Lower-Mechanismus, definiert im Canonical ABI, Teil des Component Model.
Historisch waren WebAssembly-Module strikt isoliert. Sie konnten nur primitive Werte — Integer und Fließkommazahlen — über Grenzen hinweg austauschen. Der Austausch von Strings oder Byte-Arrays erforderte explizites Speicher-Management, Zeigerübergabe und handgeschriebenen Serialisierungs-Glue-Code.
WIT (WebAssembly Interface Types) ändert das, indem es als Schnittstellen-Definitionssprache dient. Man beschreibt den Vertrag zwischen zwei Komponenten in einer .wit-Datei, und das Toolchain (wit-bindgen für Rust, jco für JavaScript/TypeScript, componentize-py für Python) generiert automatisch die notwendige Host-Glue.
Das Canonical ABI legt dann fest, wie komplexe Werte die Komponenten-Grenzen überschreiten:
- Lowering wandelt eine native Repräsentation (z.B. ein Rust
String, ein Go[]byte) in ein standardisiertes Speicherlayout um, das die empfangende Seite lesen kann. - Lifting wandelt dieses Standardlayout zurück in die native Repräsentation der empfangenden Komponente.
Wenn beide Komponenten im selben Host-Laufzeit-Instance laufen, kann die Laufzeit diese Interaktion erheblich optimieren — aber einfache Funktionsaufrufe sind synchron und blockierend. Für kontinuierlichen, entkoppelten, asynchronen Datenfluss zwischen Nano-Services braucht man etwas mehr: einen persistenten Kanal, der auf gemeinsamem Speicher basiert.
5. Syscall-freies Tunneling via speicherabbildende Ringpuffer
Syscall-freies Tunneling für co-lokalisierte WASM-Komponenten funktioniert, indem ein persistenter, asynchroner Kommunikationskanal eingerichtet wird, der vollständig im vom Host verwalteten Speicher lebt — außerhalb der linearen Speicher der einzelnen Komponenteninstanzen.
Das ist konzeptuell ähnlich zu DPDK (Data Plane Development Kit) oder AF_XDP im Linux-Umfeld: Es umgeht das Kernel-Netzwerk-Stack, um Daten direkt zwischen User-Space-Prozessen zu verschieben. Der Unterschied ist, dass hier die “Prozesse” WASM-Komponenteninstanzen sind, und die Isolationsgarantien durch Software Fault Isolation (SFI) statt Kernel-Namensräume gewährleistet werden.
Der SPSC-Lock-Free-Ringpuffer
Das zentrale Datenstruktur ist ein Single-Producer, Single-Consumer (SPSC) lock-freier Ringpuffer, der in einem gemeinsam genutzten Speicherbereich reserviert ist, den die Host-Laufzeit verwaltet. Der Puffer funktioniert wie folgt:
- Ein Producer-Komponente (der Sender) schreibt Nutzdaten in den Ringpuffer und erhöht einen atomaren
write_index. - Eine Consumer-Komponente (der Empfänger) liest von
read_index, verarbeitet die Daten und erhöht ihren eigenen atomaren Marker.
Da WASM’s Speicher-Modell garantiert, dass Komponenten außerhalb ihres explizit zugewiesenen linearen Speichers nicht lesen können, muss der gemeinsam genutzte Buffer-Bereich explizit in jede Komponente als Capabilty-Handle injiziert werden — ein WIT resource-Typ. Wenn eine Komponente nicht vom Host das bridge-channel-Resource erhält, kann sie nicht auf den gemeinsamen Speicher zugreifen.
Mit WASIp3’s nativer asynchroner I/O kann die Host-Laufzeit die Consumer-Komponente parken, ohne die CPU zu spammen, und sie bei Aktualisierung des write_index durch eine leichte Benachrichtigung wecken. Das eliminiert die Hauptnachteile des Pollings.
Keine Syscalls. Keine Kernel-Kontextwechsel. Keine Paketpuffer-Allokationen. Daten bewegen sich im RAM-Geschwindigkeit zwischen isolierten Komponenten.
Ein realistischer Blick auf Durchsatzansprüche
Behauptungen wie “Hunderte Gigabit pro Sekunde” für Shared-Memory-IPC verdienen eine kritische Betrachtung. In der Praxis hängt der Durchsatz stark von Payload-Größe, den Kosten der lift/lower-Operation, Laufzeitplanung und CPU-Cache-Verhalten ab. Was Shared-Memory-IPC tatsächlich über Loopback-TCP liefert, ist eine Reduktion der Latenz (von Mikrosekunden im niedrigen einstelligen Bereich gegenüber Millisekunden) und die Eliminierung von Kernel-Planungsjitter. Für co-lokalisierte Nano-Services, bei denen vorhersehbare, konstante niedrige Latenz wichtiger ist als maximaler Durchsatz, ist dies der entscheidende Vorteil.
6. Die Edge-to-Local WASM-Brücke
Eine der praktischsten Anwendungen des syscall-freien Tunneling ist die Verbindung eines Edge-Proxy-Komponenten mit einer Backend-Verarbeitungs-Komponente, die auf demselben physischen Host läuft.
Betrachten wir die folgende Architektur, die reale Deployment-Muster auf Plattformen wie Fastly Compute@Edge und Cloudflare Workers widerspiegelt:
- Ingress-Komponente. Ein Edge-Proxy, kompiliert zu WASM, empfängt eine eingehende HTTP/3-Anfrage, beendet TLS, authentifiziert die Anfrage und parst die relevanten Payload-Felder.
- Kanal-Schreiben. Anstatt eine interne HTTP-Anfrage zu konstruieren und über einen Loopback-Socket zu senden, schreibt die Ingress-Komponente die geparste Nutzlast direkt in einen speicherabbildenden Ringpuffer via einen
bridge-channel-Capabilty-Handle. - Verarbeitungs-Komponente. Eine Backend-WASM-Komponente — vielleicht mit
wasi-nnfür Inferenzmodelle oder einer proprietären Datenumwandlung — wird durch den asynchronen Scheduler der Host-Laufzeit geweckt, liest die Nutzlast aus dem gemeinsamen Speicher, verarbeitet sie und schreibt die Antwort in einen Rückkanal. - Antwortpfad. Die Ingress-Komponente liest die Antwort aus dem Rückkanal und sendet sie an den Client.
Keine interne HTTP-Anfrage. Kein Loopback-Socket. Kein Kernel-Beteiligung zwischen Ingress- und Verarbeitungs-Schicht.
WIT-Interface für den Bridge-Channel
package internal:zero-syscall@0.1.0;
interface tunnel {
/// Ein Capabilty-Handle, das einen speicherabbildenden Ringpuffer repräsentiert.
/// Vom Host-Laufzeit als explizite Capabilty injiziert.
resource bridge-channel {
/// Initialisiert einen Kanal, der von einem gemeinsamen Puffer mit der angegebenen Größe in Bytes unterstützt wird.
constructor(size: u32);
/// Schreibt eine Nutzlast in den Ringpuffer.
/// Gibt die Anzahl der geschriebenen Bytes oder einen Fehler zurück, wenn der Puffer voll ist.
write-payload: func(data: listcu8e) -e resultcu32, string3e;
/// Liest Bytes aus dem Ringpuffer.
/// In WASIp3 lässt sich dies als nativer `future` oder `stream`-Typ ausdrücken.
read-payload: func(max-bytes: u32) -e resultclistcu8e, string3e;
}
}
world edge-bridge {
export tunnel;
}
Hinweis: Der result-Rückgabetyp ist hier bewusst konservativ gewählt. Mit der Stabilisierung von WASIp3-Async wird die Funktion read-payload als nativer future oder stream-Typ ausgedrückt, was es der Laufzeit ermöglicht, den Verbraucher richtig zu parken, ohne zu pollern.
Rust-Producer-Seite
Mit der Toolchain wit-bindgen und cargo-component (bitte den Legacy-cargo-wasi vermeiden, der auf WASI Preview 1 zielt):
use bindings::internal::zero_syscall::tunnel::BridgeChannel;
// Der Kanal wird beim Start vom Host-Laufzeit-Embedding initialisiert,
// dann als Capabilty-Resource in diese Komponente injiziert.
// Dies ist KEIN globales Objekt, das die Komponente selbst aus dem Nichts erstellt.
static CHANNEL: std::sync::OnceLockcBridgeChannele = std::sync::OnceLock::new();
#[export_name = "handle-edge-request"]
pub extern "C" fn handle_request(ptr: *const u8, len: usize) {
let payload = unsafe { std::slice::from_raw_parts(ptr, len) };
// Routing-Logik, Authentifizierungschecks etc.
if is_authorized(payload) {
let channel = CHANNEL.get().expect("channel not initialized by host");
// Schreibt direkt in den gemeinsam genutzten Ringpuffer.
// Kein Syscall. Kein Serialisierungs-Overhead außer Lift/Lower.
match channel.write_payload(payload) {
Ok(bytes_written) => {
// Bytes geschrieben, ggf. Log
}
Err(_e) => {
// Backpressure-Handling — der Ringpuffer ist voll.
// Hier Retry-Logik oder Drop-Policy implementieren.
}
}
}
}
Der zentrale Punkt: Die Lifecycle-Management des BridgeChannel-Resources liegt beim Host-Laufzeit-Embedding. Die Komponente erhält es als injiziertes Capabilty-Handle — sie kann keinen Kanal zu einer anderen Komponente selbst herstellen.
7. Reale Einsatzkontexte
Edge AI Inferenz
Der wasi-nn-Vorschlag, der eine Standard-API für das Ausführen neuronaler Netz-Inferenz innerhalb einer WASM-Komponente bietet, gewinnt 2026 zunehmend an Verbreitung. Cloudflare hat im Februar 2026 Llama 3.1 8B und Llama 3.2 11B Vision-Modelle in über 330 Edge-Standorten eingesetzt, mit Cold-Start-Zeiten unter 5 ms, basierend auf ihrer V8-Isolat-Architektur.
Bei KI-Inferenz-Workloads ist oft die Flaschenhals die Kopie großer Eingabetensoren (Audio-Schnipsel, Bildpuffer, Embedding-Batches) in den Speicherbereich des Inferenz-Engines. Ein speicherabbildender Bridge-Channel eliminiert die Serialisieren-Senden-Deserialisieren-Runde, was bei einem 1MB-Bildtensor mehrere Hundert Mikrosekunden Latenz pro Inferenz spart.
Hochfrequente Datenverarbeitung
Bei automatisiertem Bieten und Marktdaten-Normalisierung liegt das Latenzbudget zwischen Signalempfang und Antwort oft unter einer Millisekunde. Das Co-Lokalisieren eines ingress-WASM-Komponenten und einer Verarbeitungs-WASM-Komponente auf demselben Edge-Host, verbunden durch einen Ringpuffer, ermöglicht es, dieses Budget einzuhalten, ohne dass eine der Komponenten mit dem OS-Netzwerkstack interagieren muss. American Express hat eine interne FaaS-Plattform auf wasmCloud aufgebaut, die dieses Pattern in der Praxis demonstriert.
Service Mesh und eBPF-Integration
Die Proxy-Wasm-Spezifikation erlaubt WASM-Filter in Envoy und ähnlichen Proxies. Die nächste Entwicklungsstufe ist die Kombination von eBPF-Paketverarbeitung — die Pakete auf NIC-Ebene abfängt und den Großteil des Kernel-Netzwerk-Stacks umgeht — mit WASM-Komponenten. Ein eBPF-Programm kann Pakete direkt in einen Speicherbereich DMA-en, den eine WASM-Komponente liest, und so eine Zero-Syscall-Pipeline vom physischen NIC bis zur Sandbox-Logik schaffen. Dies ist noch ein aktives Forschungs- und Entwicklungsfeld im Jahr 2026, kein standardisiertes Deployment.
8. Sicherheit: Ist Shared Memory in einem WASM-Kontext sicher?
Wenn man den Kernel umgeht, ist die naheliegende Sorge, dass man auch die Isolationsgarantien des Kernels umgeht — Namespaces, cgroups, seccomp-Filter. Im WASM-Kontext ist die Antwort, dass man eine Isolationsmechanismus durch einen anderen ersetzt, und in mehreren Aspekten ist das WASM-Modell sogar robuster.
WebAssembly nutzt Software Fault Isolation (SFI): Jeder Speicherzugriff, den eine WASM-Komponente macht, wird auf Instruktionsniveau gegen den zugewiesenen linearen Speicherbereich validiert. Eine Komponente kann buchstäblich keinen Zeiger außerhalb ihres linearen Speichers generieren. Der shared Ringpuffer ist nur zugänglich, wenn der Host-Laufzeit ihr explizit das bridge-channel-Capabilty-Handle injiziert. Verweigerung standardmäßig wird auf mathematischer Ebene durchgesetzt, nicht durch Konfiguration.
Das adressiert drei Vulnerabilitätsklassen:
Capability-Konfinement. Eine Komponente, die das Tunnel-Handle nicht hat, kann den Buffer nicht entdecken, darauf zugreifen oder die Adresse erraten. Es gibt keine Äquivalente zu Dateideskriptor-Lecks oder /proc/mem-Exploits.
Schadensbegrenzung. Bei einem Bug, der einen Buffer-Overrun innerhalb des eigenen linearen Speichers verursacht, fängt die Laufzeit den unreachable-Trap, beendet die Instanz und startet sie neu — ohne die andere Seite des Tunnels zu beeinträchtigen. Das steht im Gegensatz zu herkömmlicher Shared-Memory-IPC in C++ oder C, bei der ein Buffer-Overflow in einem Prozess den Heap des Nachbarprozesses beschädigen kann.
Keine OS-Dateideskriptoren. Da keine Sockets geöffnet werden, hält die Komponente niemals einen OS-File-Descriptor. Das eliminiert ganze Vulnerabilitätsklassen: Ressourcenerschöpfung durch Deskriptoren, Socket-Hijacking und bestimmte Kernel-Heap-Spraying-Techniken, die auf fd-Manipulation setzen.
Der Caveat ist, dass SFI vor logischen Fehlern beim Validieren der Daten vor dem Schreiben oder Lesen in den Shared Buffer nicht schützt. Input-Validierung und Schema-Checks bleiben die Verantwortung des Anwendungsentwicklers, wie bei jedem IPC-System.
9. Ehrliche Grenzen und was sich noch entwickelt
Eine verantwortungsvolle Betrachtung dieses Themas nennt, was noch nicht reibungslos funktioniert.
WASIp3 async ist noch RC. Die nativen future- und stream-Typen, die eine saubere, nicht-pollende asynchrone Kommunikation zwischen Komponenten ermöglichen, befinden sich Anfang 2026 im Release-Candidate-Status. Die API könnte sich noch ändern. Für den produktiven Einsatz sollten Stable- oder LTS-Releases von Wasmtime verfolgt werden.
Threading fehlt. Die Unterstützung von Threads außerhalb des Browsers ist noch unfertig. Das schließt ganze Kategorien rechenintensiver Workloads aus, bei denen Parallelität innerhalb einer Komponente notwendig ist. Das hier beschriebene Zero-Syscall-Tunnel-Pattern erfordert kein Threading innerhalb einer einzelnen Komponente, setzt aber voraus, dass der Host mehrere Instanzen gleichzeitig planen kann.
Netzwerk-I/O ist noch langsamer als native. Laut einer Analyse in Java Code Geeks im April 2026 ist das WASI-Netzwerk-Stack noch im Aufbau und fehlt die Kernel-Optimierungen, die Linux-Netzwerke über Jahrzehnte angesammelt haben. Statisches File-Serving ist in WASM im Vergleich zu gut optimierten Containern immer noch langsamer. Der Zero-Syscall-Tunnel adressiert speziell die intra-node-Kommunikation; für externe Netzwerke ist WASM noch mit Overhead belastet.
Expertise ist noch Spezialwissen. Die Nutzung von Wasmtime-Embeddings, WIT-Interface-Design, wit-bindgen-Toolchain und Capabilty-Resource-Injection ist noch nicht im Skillset der meisten Engineering-Teams. Das ist eine echte Deployment-Hürde.
WASI 1.0-Stabilität liegt noch vor uns. Unternehmen, die langfristige API-Stabilität brauchen, warten auf WASI 1.0, das derzeit für Ende 2026 oder Anfang 2027 geplant ist.
10. Der Blick nach vorn
Das WebAssembly-Ökosystem ersetzt Container nicht im Großen und Ganzen — die Java Code Geeks-Analyse ist richtig, wenn sie beobachtet, dass niemand eine allgemeine Microservices-Backend-Architektur auf WASM in großem Maßstab betreibt. Was passiert, ist, dass spezifische, sorgfältig ausgewählte Nischen — Edge-Compute, serverlose FaaS, Plugin-Systeme, Inferenz-Serving — durch die Stärken von WASM transformiert werden: nahezu keine Cold-Starts, dichte Multi-Tenancy, portable Binärdateien und Capabilities-basierte Isolierung.
Das Zero-Syscall-Netzwerk ist der natürliche nächste Schritt dieser Transformation. Sobald WASIp3 stabil ist und Threading kommt, wird die Kombination aus:
- Native Async-Streams für nicht-blockierende Inter-Komponenten-Kommunikation
- Shared Memory Ring Buffers für Zero-Copy-Datenübertragung
- WIT-Interface-Definitionen für typsichere, sprachübergreifende Verträge
- SFI-Isolierung für Sicherheit ohne Kernel-Overhead
…es ermöglichen, co-lokalisierte WASM-Nano-Services zu einer echten Alternative zu herkömmlicher Microservice-Kommunikation bei latenzkritischen Workloads zu machen.
Die Zukunft des Edge ist nicht nur serverless. Für eine wachsende Anzahl von Anwendungsfällen wird sie socketless.
Quellen und weiterführende Literatur: Bytecode Alliance Component Model Dokumentation unter component-model.bytecodealliance.org; WASI-Roadmap unter wasi.dev; Wasmtime-Dokumentation und Release Notes; Spin v3.5 Release Notes (Fermyon); WebAssembly 3.0 W3C-Spezifikation (September 2025); Java Code Geeks “WebAssembly in 2026”-Analyse (April 2026); State of WebAssembly 2025–2026, Uno Platform Blog (Januar 2026).
Keep building with InstaTunnel
Read the docs for implementation details or compare plans before you ship.