REVIEW 3 major objections 5 minor 22 references
WASP: A Configurable Framework for Portable Stateful Serverless Applications
T0 review · 3 major / 5 minor · reviewed 2026-08-01 · deepseek-v4-flash
Pith's one-line read WASP shows that stateful WebAssembly serverless applications can be made portable and configurable—runtimes and datastores swap without touching application code.
desk verdict A useful modular stateful WASM FaaS framework with an honest configurability evaluation, but the 'negligible overhead' claim rests on a mismatched baseline and needs an ablation. read the letter →
The pith
A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.
The reading
What carries the argument
The key mechanism is the adapter pattern in front of each pluggable component. The WASM Runtime Adapter exposes a uniform WASM Execution API that wraps compilation, instantiation, invocation, and memory-boundary traversal for runtimes as different as C/Rust JIT engines and pure-Go AOT runtimes, parameterizing the executor pool's concurrency model. The Storage Adapter exposes a uniform state management API (get/put) with a linear-memory sharing protocol for host functions, so the same .wasm binary can talk to Redis or PostgreSQL. The Function Manager's two-level cache—a raw-binary artifact cache with singleflight and an LRU compiled-module cache—makes warm starts nearly as fast as native exec
What would settle it
Run the same workload three ways: full WASP with a stub storage adapter, WASP with the HTTP layer and worker pool stripped out but adapters retained, and the standalone runtime CLI behind the same HTTP front-end. If full-WASP end-to-end latency exceeds the stripped version by more than the paper's reported overhead on a given benchmark, the 'negligible overhead' claim is falsified.
Extended reading notes
Core claim
The central discovery is an architecture, not a single algorithm: by strictly decoupling the Function Manager (with its executor pool and two-level cache) from the WASM runtime and storage backends through adapter interfaces, WASP makes the execution environment a deployment-time configuration. Applications compiled to WASM call get/put through a uniform state management API; the runtime adapter handles engine-specific memory and concurrency, and the storage adapter maps the API onto the chosen datastore. The paper reports that swapping these components yields radically different performance and memory profiles—for example, interpreted versus ahead-of-time compilation on the same runtime cha
Load-bearing premise
The 'negligible overhead' conclusion assumes the standalone runtime CLI is a fair baseline that isolates WASP's cost, but that CLI has no HTTP front-end, worker pool, or cache, so the comparison may understate WASP's true overhead.
Editorial extensions
If this is right
- A single application binary can be deployed unchanged from server-class machines to low-memory edge devices; the paper demonstrates this on a Raspberry Pi.
- Swapping execution modes changes cold-start latency by orders of magnitude, letting operators choose the right CPU-to-memory trade-off per workload.
- Warm execution via the module cache lands within a small constant factor of native Go (0.08ms for Fibonacci on Wasmtime-AOT), so per-request overhead is dominated by the runtime, not WASP.
- Datastore choice becomes a configuration decision with measurable effect on warm stateful calls (Redis ~0.19ms vs PostgreSQL ~1.49ms on Wasmtime-AOT).
- Adding a new runtime or datastore costs only the adapter code (245–317 lines for runtimes, 53–76 for stores), so the platform can track the WASM ecosystem cheaply.
Reading between the lines
- If the overhead result survives an ablation that separates the HTTP front-end and worker pool from the adapter layer, the same architecture could support dynamic runtime selection per invocation, letting a scheduler move functions between interpreter and AOT engines based on observed load.
- The singleflight artifact cache suggests a straightforward extension to multi-node deployments: a shared registry plus local caches could keep cross-node invocation stampede-free, something the paper does not test.
- The uniform get/put state API could be extended with multi-key transactions or versioned reads without changing the portability argument, since the adapter would simply map richer semantics onto the backend.
- The paper's comparison with the state-of-the-art framework leaves open how WASP behaves under skewed or bursty workloads; a test with non-uniform request arrival would locate the pragmatic ceiling of the FIFO scheduler.
Signed reviews
Editorial analysis
A structured set of objections, weighed in public.
Referee Report
Summary. The paper introduces WASP, a stateful WebAssembly serverless framework built from decoupled, pluggable components: a Function Manager with an executor pool and multi-level cache, a WASM Runtime Adapter, and a Storage Adapter exposing a uniform get/put state API. The authors argue that, by keeping these components interchangeable, WASP lets administrators swap WASM runtimes and datastores without changing application code, and that this configurability comes at negligible runtime overhead. The evaluation covers three runtimes (Wasmtime, Wazero, WasmEdge), two datastores (Redis, PostgreSQL), several execution modes, a comparison with Sledge, and a Raspberry Pi deployment. The central claims are that WASP's abstraction layer adds negligible overhead and that different configurations expose radically different latency/memory profiles, confirming adaptability across the edge-cloud continuum.
Significance. If the claims are sustained, WASP would make a useful contribution: it targets a real gap in today's WASM FaaS systems, which are typically monolithic and either stateless or tied to one runtime/backend. The paper's strengths include a genuinely modular architecture, adapter cost reported in lines of code (Wazero 245, Wasmtime 263, WasmEdge 317; Redis 53, PostgreSQL 76), concrete integration of three substantially different runtime execution models, and an edge deployment on a Raspberry Pi. The comparison against Sledge on lightweight workloads is informative and not circular. The main gap is that the 'negligible overhead' claim is not yet adequately supported by the evaluation methodology, so the paper's headline result requires stronger experimental evidence or a substantially qualified wording.
major comments (3)
- [§4.2, RQ2, Table 1] The central claim that WASP introduces 'negligible runtime overhead' is not supported by the chosen baselines. WASP's 'Cold' is the first request served by an already-running service (engine initialized, worker pool alive, caches empty), while the standalone CLI's 'Cold' includes OS process startup and one-shot engine initialization. The paper itself attributes WASP's lower cold-start time to amortizing runtime initialization across invocations, which confirms the two quantities are not measuring the same thing. Moreover, no standalone warm-start measurement is reported at all, and the stateful workload has no standalone stateful baseline, so the get/put adapter cost is unmeasured. A proper overhead assessment needs an ablation that isolates WASP's framework layer, e.g., WASP with and without adapters under identical process-warm/module-cold conditions, or a same-process baseline without
- [§4.2, RQ2, Table 1] All quantitative conclusions are based on point estimates without variance. For example, the paper states that 'on Hash, the two converge within 4% (180.6 vs. 187.7ms)' and concludes 'no measurable cost.' Without confidence intervals, standard deviations, or at least per-repetition data, a 4% difference cannot be distinguished from noise, especially with only 10 averaged runs for Hash. The same issue affects the warm-start speedup claims and the memory comparisons. Since RQ1 and RQ2 are the backbone of the paper's central claims, the tables need error bars or statistical significance measures.
- [§4.2, RQ2 and §5] The 'negligible overhead' claim is unqualified with respect to memory. The evaluation reports that WASP's peak RSS exceeds the standalone runtime by 10–50 MB, and for the stateful AOT configurations the gap is much larger (e.g., WasmEdge AOT stateful at 180 MB vs. 41 MB for the interpreted configuration). On memory-constrained edge devices, this is not obviously 'negligible.' The paper should either restrict the overhead claim to execution time, or add a qualified statement that the memory overhead is an explicit cost of the framework's caching and worker-pool design, and discuss its impact on the edge deployment scenarios claimed in the introduction.
minor comments (5)
- [Table 1] The column headers are ambiguous. The table appears to contain two sets of Cold/Warm/RSS columns for Fibonacci and Hash, and later for Redis/PostgreSQL stateful runs, but the header row does not explicitly label which pair belongs to which workload or backend. This makes the table hard to read without inferring from the text.
- [§4.1, Figure 2] Figure 2 reports throughput and latency without confidence intervals or statistical significance annotations. Since the comparison with Sledge is a key RQ3 result, at least marking the spread across the 10 repetitions would help assess whether the observed differences are stable.
- [§3.2, §4.2] The paper uses 'Cold' and 'Warm' without formal definitions in the main text. Specifically, it should state explicitly that WASP 'Cold' is first-request-without-cached-module while the process is already running, and that 'Standalone' has no warm variant. Adding a sentence or a footnote would prevent the misinterpretation that the paper is comparing the same start condition.
- [§4.2, RQ3] The Sledge comparison covers only CPU-bound stateless workloads. Since the paper's contribution is stateful execution, it would be useful to at least discuss why a stateful comparison is not possible (e.g., Sledge's lack of a state API) and whether the throughput results could be affected by state operations in a more realistic mixed workload.
- [General] Minor typos and formatting inconsistencies exist, such as the title being rendered as 'W ASP' in the header and the lack of a space in 'W ASM' in the abstract. The reference list also contains a few inconsistent name abbreviations; a final proofread would be helpful.
Circularity Check
No significant circularity: WASP's claims are supported by external benchmarks and direct measurements, not by fitting or self-referential derivation.
full rationale
WASP is a systems paper whose central claims—configurability, negligible overhead, and edge portability—are evaluated by direct measurement against external baselines: standalone WASM runtimes invoked via their native CLIs, native Go execution, and the third-party Sledge framework. There is no fitted parameter that is later renamed a prediction, no quantity is defined in terms of the quantity it is said to predict, and no load-bearing argument reduces to a self-citation. The only notable methodological concern is the comparability of the standalone-CLI cold-start baseline with WASP's already-running service (the CLI includes process startup while WASP amortizes runtime initialization), which the paper itself acknowledges when it attributes WASP's lower cold-start times to amortized runtime initialization. That is a threat to the precision of the 'negligible overhead' claim, but it is a benchmarking-validity issue, not a circularity: WASP's overhead is not constructed from the baseline, and the comparison is to an external artifact rather than to the paper's own outputs. No circular step can be exhibited by quoting equations or definitions that collapse into one another. Accordingly, the circularity score is 0.
Assumptions & free parameters
free parameters (2)
- Executor pool size =
32 workers (server-class); Sledge uses 30
- Module Cache LRU capacity =
not reported
assumptions (4)
- domain assumption WASM is a lightweight, efficient alternative to containers for edge FaaS
- domain assumption The three runtimes (Wasmtime, Wazero, WasmEdge) are representative of the WASM runtime space
- domain assumption A get/put state interface is sufficient for stateful serverless applications
- standard math WASM host-function calls via linear memory offsets are safe and adequate for state exchange
Cite this review
Pith. "Pith review of WASP: A Configurable Framework for Portable Stateful Serverless Applications." pith.science (2026). https://pith.science/paper/REQTNCOU
@misc{pith2026260725493,
author = {Pith},
title = {Pith review of: WASP: A Configurable Framework for Portable Stateful Serverless Applications},
year = {2026},
howpublished = {\url{https://pith.science/paper/REQTNCOU}},
note = {Machine review of arXiv:2607.25493}
}
read the original abstract
WebAssembly (WASM) is emerging as a lightweight alternative to containers for Function-as-a-Service (FaaS) across the edge-cloud continuum. However, existing WASM-based serverless platforms are tightly coupled to specific execution engines and predominantly designed for stateless workloads. This clashes with the heterogeneity of edge deployments, which demand support for stateful applications under diverse hardware and workload constraints. We introduce WASP, a configurable framework that brings stateful serverless execution to the edge-cloud continuum. By abandoning monolithic architectures in favor of strictly decoupled, pluggable components, WASP lets system administrators swap the WASM runtime and the datastore to fit available resources and application requirements, without altering application code. Configurable lifecycle and caching policies further enable fine-tuning for diverse non-functional requirements. Our experimental evaluation demonstrates that WASP introduces negligible runtime overhead and, by swapping runtimes, datastores, and policies, exposes radically different memory and latency profiles, confirming its adaptability to the heterogeneous constraints of the edge-cloud continuum.
Figures
Reference graph
Works this paper leans on
-
[1]
Bittencourt, L.F., Rodrigues-Filho, R., Spillner, J., De T urck, F., Santos, J., da F onseca, N.L., Rana, O., Parashar, M., F oster, I.: The computing continuum: Past, present, and future. Comp. Science Review58(2025)
2025
-
[2]
In: Middleware
Gadepalli, P .K., McBride, S., Peach, G., Cherkasova, L., Parmer, G.: Sledge: a serverless-first, light-weight wasm runtime for the edge. In: Middleware. ACM (2020)
2020
-
[3]
IEEE Commun
Hoque, M.N., Harras, K.A.: W ebAssembly for edge computing: Potential and challenges. IEEE Commun. Standards Mag.6(4) (2022)
2022
-
[4]
In: SOSP
Jia, Z., Witchel, E.: Boki: Stateful serverless computing with shared logs. In: SOSP . ACM (2021)
2021
-
[5]
In: GIIS
Khelifa, S.e., Bagaa, M., Messaoud, A.O., Ksentini, A.: Case study of webassembly runtimes for ai applications on the edge. In: GIIS. IEEE (2024)
2024
-
[6]
Kimovski, D., Mathá, R., Hammer, J., Mehran, N., Hellwagner, H., Prodan, R.: Cloud, fog, or edge: Where to compute? Internet Comp.25(4) (2021)
2021
-
[7]
Liu, M., Shen, H., Zhang, Y., Mei, H., Ma, Y.: W ebassembly for container runtime: Are we there yet? ACM TOSEM34(6) (2025)
2025
-
[8]
IEEE Internet Comp.21(2017)
Nastic, S., Rausch, T., Scekic, O., Dustdar, S., Gusev, M., Koteska, B., Kostoska, M., Jakimovski, B., Ristov, S., Prodan, R.: A serverless real-time data analytics platform for edge computing. IEEE Internet Comp.21(2017)
2017
Show all 22 references
-
[9]
IEEE TPDS (2025)
Pang, X., Liu, L., Zhang, Y., Chen, Z., Ding, Z., Cheng, D., Zhou, X.: F eatherlight stateful webassembly for serverless inference workflows. IEEE TPDS (2025)
2025
-
[10]
In: MiddleWEdge
Pfandzelter, T., Bermbach, D.: Enoki: Stateful distributed F aaS from edge to cloud. In: MiddleWEdge. ACM (2023)
2023
-
[11]
Software: Practice and Experience 53(10) (2023)
Pfandzelter, T., Japke, N., Schirmer, T., Hasenburg, J., Bermbach, D.: Managing data replication and distribution in the fog with FReD. Software: Practice and Experience 53(10) (2023)
2023
-
[12]
In: HotEdge
Rausch, T., Lachner, C., F rangoudis, P .A., Raith, P ., Dustdar, S.: Synthesizing plausible infrastructure configurations for evaluating edge computing systems. In: HotEdge. USENIX Association (2020)
2020
-
[13]
Schleier-Smith, J., Sreekanti, V., Khandelwal, A., Carreira, J., Y adwadkar, N.J., Popa, R.A., Gonzalez, J.E., Stoica, I., Patterson, D.A.: What serverless computing is and should become: The next phase of cloud computing. Commun. ACM64(5) (2021)
2021
-
[14]
IEEE IoT Jour.3(2016)
Shi, W., Cao, J., Zhang, Q., Li, Y., Xu, L.: Edge computing: Vision and challenges. IEEE IoT Jour.3(2016)
2016
-
[15]
In: USENIX A TC
Shillaker, S., Pietzuch, P .: F aasm: Lightweight isolation for efficient stateful serverless computing. In: USENIX A TC. USENIX Association (2020)
2020
-
[16]
VLDB13(12) (2020)
Sreekanti, V., W u, C., Lin, X.C., Schleier-Smith, J., Gonzalez, J.E., Hellerstein, J.M., T umanov, A.: Cloudburst: Stateful functions-as-a-service. VLDB13(12) (2020)
2020
-
[17]
ACM Comp
V arghese, B., W ang, N., Bermbach, D., Hong, C.H., Lara, E.D., Shi, W., Stewart, C.: A survey on edge performance benchmarking. ACM Comp. Surv.54(3) (2021)
2021
-
[18]
ACM TOSEM32(5) (2023)
W en, J., Chen, Z., Jin, X., Liu, X.: Rise of the planet of serverless computing: A systematic review. ACM TOSEM32(5) (2023)
2023
-
[19]
In: ISP A
W en, Y., Xu, G., W ang, J., Hao, W.: Low-latency state management for real-time tasks in edge serverless. In: ISP A. IEEE (2024)
2024
-
[20]
In: OSDI
Zhang, H., Cardoza, A., Chen, P .B., Angel, S., Liu, V.: F ault-tolerant and transactional stateful serverless workflows. In: OSDI. USENIX Association (2020)
2020
-
[21]
ACM TOSEM34(8) (2025)
Zhang, Y., Liu, M., W ang, H., Ma, Y., Huang, G., Liu, X.: Research on webassembly runtimes: A survey . ACM TOSEM34(8) (2025)
2025
-
[22]
Ţălu, M.: A comparative study of webassembly runtimes: Performance metrics, integra- tion challenges, application domains, and security features. Arch. Adv. Eng. Sci. (2025)
2025
Reviewed August 1, 2026 · model on record in the stance chip above.
Discussion (0). Continue with ORCID to comment.