## 5 State-of-the-Art
### Serverless  
In [93], an examinination was conducted into a serverless edge computing architecture through a Wasm-based approach, comparing its performance to native and container-based applications using the ARM architecture toolchain. The benchmarks for comparison included several types of applications, including compute-intensive, memory-intensive, and file I/O-intensive applications, along with a basic image classification machine learning application. The paper presented the experimental setup, performance results, and conclusion. Sledge was proposed in [94], which is a Wasm-based serverless framework for edge computing. Sledge is designed for the unique needs of serverless workloads, including high-density multi-tenancy, low startup time, and short-lived computations. Using optimized scheduling policies and efficient work distribution, Sledge offers a lightweight function isolation model implemented with Wasm-based software fault isolation infrastructure. Compared to Nuclio, an open-source serverless framework, Sledge achieved up to four times higher throughput and four times lower latency. Another article [95] examined the use of Wasm as a lightweight alternative to container technologies such as Docker for serverless functions, with a focus on edge computing settings. The paper presented a Wasm-based runtime environment for serverless edge computing, called WOW, which significantly reduced cold-start latency, improved memory consumption, and enhanced function execution throughput on low-end edge computing equipment compared to Docker-based container runtime. Another work [96] discussed the recent developments that enable Wasm to be used for server-side applications and serverless functions. The goal of this work was to integrate Wasm with existing cloud and edge infrastructure. While Wasm has been identified as a solution to the cold start problem in serverless platforms, this study concluded that further work is needed and suggested the support of multiple runtime environments in addition to Wasm. Another study [97] investigated the potential of Wasm to transform serverless computing. Wasm's strengths, such as reduced cold start times, efficiency, easy portability, and compatibility with popular programming languages,were evaluated using a benchmarking suite comprised of thirteen different functions. An initial step towards integrating Wasm runtimes with the APIs and command line interfaces of popular container runtimes was discussed. In the results the Wasm runtimes outperformed contained runtimes on ten out of thirteen tests, with Wasmtime being the fastest Wasm runtime. In [98], the authors introduced a nomenclature for characterizing serverless function access patterns to derive the basic requirements of a serverless computing runtime. Their paper proposed the use of Wasm as an alternative method for running serverless applications. They showed that a Wasm-based serverless platform can provide the same isolation and performance guarantees as container-based platforms while having reduced application start times and requiring fewer resources. A white paper expresses the security aspects of Wasm in the _libc_ implementation [99]. This extension can help Wasm compilers and JITs to enforce different models of memory safety depending on user preferences and available hardware on the target platform. MS-Wasm offers a range of security-performance trade-offs, and allows users to move to progressively stronger models of memory safety as hardware evolves. The comprehensive survey in [100] discusses the suitability of serverless computing for IoT data processing at the edge in consideration of the limitations of existing solutions based on VMs and containers. It introduces a Wasm-based serverless framework, aWsm, to manage efficient serverless operations at the edge, with opportunities for function profiling and SLO-driven performance management.