An Overview of WebAssembly for IoT: Background, Tools, State-of-the-Art, Challenges, and Future Directions

1.1. Background and Significance

1.2. Motivation

1.3. Objectives

1.4. Contributions

1.5. Organization of the Paper

2.1. Overview of WebAssembly

• The Rationale Behind WebAssembly
  The introduction of Wasm was in response to the need for an efficient low-level code representation that could be processed effectively within the stringent performance constraints of web environments. Over the course of their evolution, web applications have grown in complexity, requiring more computational resources and demanding superior performance from client-side scripts. JavaScript, while instrumental in the development and functionality of these applications, has limitations in terms of performance optimization that have become more evident with the increasing complexity of web tasks. Wasm was developed to address this performance gap, complementing JavaScript by running complex computational tasks at near-native speed. This leap in performance opens up new possibilities for web-based applications, allowing them to handle more complex tasks that have traditionally been the domain of desktop applications.
• Portability and Interoperability
  A key attribute of Wasm is its design as a portable bytecode that can be executed across a variety of platforms. This universality makes it a versatile tool in heterogeneous environments, including the IoT, where devices of various types are interconnected. A Wasm module can run on any platform that hosts a compliant Wasm virtual machine, irrespective of the device’s specific hardware or operating system. The interoperability of Wasm is another key aspect of its design. It is designed to work in conjunction with JavaScript, leveraging the existing web platform’s infrastructure. This interoperability allows for a smoother transition to Wasm, as developers can gradually replace performance-critical sections of JavaScript code with more efficient Wasm modules without disrupting the application’s overall functionality.
• Safety and Security
  Web technologies must prioritize safety and security, and Wasm is no exception. Wasm operates inside a secure sandbox environment separate from the host system, much as JavaScript does. This design restricts any potential malicious activity within the confines of the sandbox, providing a crucial layer of security. Even if an attacker manages to exploit a vulnerability within the Wasm code, they will be contained within the sandbox environment, mitigating the potential damage to the host system.
• Evolution and Community Engagement
  Wasm has received substantial interest and support from both the developer community and industry giants such as Google, Mozilla, Microsoft, and Apple. This widespread backing coupled with active community engagement has fostered rapid evolution. There have been numerous improvements and extensions to the Wasm specification since its initial release, highlighting the ongoing development of this powerful technology. The community engagement around Wasm drives its evolution and aids in exploring new possibilities for its application across various domains, including IoT. The continued research and development efforts around Wasm, including exploring potential use cases, improving security measures, and refining its performance, ensure its place at the forefront of web and IoT technologies.
• High-Level Goals of WebAssembly
  The primary objectives of Wasm can be summarized as follows:

  –

  Establish a binary format that is portable and efficient, serving as a target for compilation to achieve native execution speed on a wide range of platforms, including mobile and IoT devices.

  –

  Implement the standard in incremental stages, beginning with a Minimum Viable Product (MVP) that offers functionality comparable to asm.js, with a specific focus on C/C++ development. Additional features, such as threads, zero-cost exceptions, and Single Instruction and Multiple Data Stream (SIMD), including support for languages beyond C/C++, will be introduced based on feedback and priorities.

  –

  Ensure seamless integration with the existing web platform by aligning with its evolutionary nature, maintaining compatibility with JavaScript, enabling synchronous communication with JavaScript, adhering to security policies such as same-origin and permissions, accessing browser functionality through existing Web Application Programming Interfaces (APIs), and providing a human-readable text format that can be converted to and from the binary format, supporting the “View Source” functionality.

  –

  Support non-browser embeddings, enabling the usage of Wasm in diverse environments beyond the web.

  –

  Enhance the platform by developing a new LLVM backend and accompanying clang port specifically for Wasm, encouraging the adoption of other compilers and tools targeting Wasm and fostering the development of additional useful tooling to enrich the Wasm ecosystem.

2.2. WebAssembly Architecture

• Overview
  Wasm is a stack-based virtual machine, which has significant implications for its design and operation. Stack-based machines use a stack to manage computations, which means that operands are pushed onto the stack, operations are performed on the top elements of the stack, and results are stored on the stack. This design makes the architecture of the virtual machine simple and efficient.
• Stack-Based Design
  The stack-based design of Wasm is a significant factor contributing to its portability and efficiency. Stack machines are inherently simpler than register machines, as they have no need to manage and allocate registers. Furthermore, stack machines are agnostic to the specifics of the host’s physical machine architecture. This means that the same Wasm code can be run consistently across different platforms, enhancing its portability. Wasm’s design is based on a stack machine model. This means that it performs computations using a stack data structure where operands are pushed onto the stack; operators pop operands off the stack and push the results back onto it. This design enhances the portability of the Wasm binary format and helps to simplify the process of validation and execution. In addition, the stack machine model results in highly compact bytecode. In a register-based machine model it is necessary to specify the register for each operand and result. In contrast, a stack-based machine model implicitly uses the top of the stack, eliminating the need for such specifications and yielding a smaller binary size.
• WebAssembly Modules
  Wasm code is organized into modules, which are the unit of deployment, loading, and compilation. These modules are stateless and can be statically analyzed, which contributes to both the safety and efficiency of Wasm. Modules declare the types, functions, tables, memories, and globals that they use, and these declarations form the basis of Wasm’s structured control flow. In Wasm, a module is a binary format file that contains a program’s compiled code along with all the data and information necessary to execute it. Each module includes a series of sections that specify types, functions, imports, exports, memory, data, tables, elements, globals, and more. Wasm modules are stateless and side-effect-free, meaning that they do not have access to any state or perform any operations unless they explicitly receive access from the host environment. This characteristic ensures isolation between modules and their host environment, improving security.
• Linear Memory Model
  Wasm uses a linear memory model. Each Wasm module has access to a single resizable array of bytes, known as its linear memory. This memory is sandboxed from the host environment and other instances, and is accessed using integer indices. This design simplifies memory management and improves safety by isolating the memory of different instances. This memory is initialized during instantiation of the module, and can be accessed and manipulated through memory instructions provided by Wasm. While this model may seem limiting, it is important to note that each Wasm module can have its own memory, allowing for isolation of different Wasm programs. Additionally, the host environment can create and provide shared memory to Wasm modules, enabling communication and shared memory concurrency between Wasm threads.
• Direct Memory Access
  Wasm operates a linear memory model that is directly accessible by the program through load and store operations. This direct memory access is a fundamental aspect of Wasm’s design and performance efficiency. Memory in Wasm is a resizable array buffer, and every load or store operation accesses this buffer directly. Load and store instructions specify an immediate offset as well as the alignment for effective memory access. This means that programs can read and write data to memory one byte at a time if needed, or in larger chunks when it is more efficient. Importantly, this direct memory access does not compromise safety. Even though the program can read and write directly from and to memory, every access is checked to ensure that it falls within the bounds of the Wasm module’s memory. If an out-of-bounds memory access is attempted, a runtime error is triggered, halting execution and preventing any data corruption or security breach.
• Control Flow
  Control flow in Wasm revolves around structured constructs that facilitate the design of a wide array of programs and algorithms. These constructs include common elements such as loops and conditionals along with function calls and returns, forming the building blocks of Wasm’s control flow. Wasm employs a structured control flow, meaning that control flow constructs such as loops and conditionals have clearly defined entry and exit points. This structure significantly simplifies the validation, compilation, and optimization of Wasm programs. Moreover, control flow in Wasm is designed to be robust and resilient, limiting potential security vulnerabilities. This is particularly evident in how the language prevents unbounded jumps or “gotos,” limiting possible control flow graphs to structured and predictable patterns. As a result, Wasm’s control flow enables the construction of complex programs while ensuring that their execution remains safe and secure.
• Interacting Elements
  Wasm has been designed with deep interaction and interoperability in mind. This extends not only to the interaction between Wasm modules and the hosting environment, but between multiple Wasm modules and between Wasm and JavaScript. The elements within a Wasm module, such as functions, globals, tables, and memories, interact in well-defined ways. Functions can be called with parameters and return results, globals can be read from and written to, tables allow for dynamic function dispatch, and memories provide the raw storage for application data. These interactions are carefully controlled to ensure the safety and reliability of Wasm applications.

  –

  WebAssembly and JavaScript

  One of the key features of Wasm is its ability to work seamlessly with JavaScript. Wasm and JavaScript can interact through a set of APIs that allows them to share data and functions. JavaScript can create a Wasm module instance and call its exported functions, while Wasm can call into JavaScript through imported functions. They can share data via Wasm’s linear memory or through JavaScript objects.

  –

  WebAssembly and the Host Environment

  Wasm modules interact with their host environment through a system of imports and exports. A module can export functions, memory, tables, and global variables that can be used by the host or by other modules. Conversely, a module can import functions and variables from the host, allowing it to interact with the outside world. This makes Wasm a highly adaptable technology that can be integrated into a wide variety of host environments.

  –

  Multiple WebAssembly Modules

  Multiple Wasm modules can interact and work together within a single application. This is done by instantiating the modules with appropriate imports from other modules, allowing them to share functions, memory, tables, and globals. This modular design supports the creation of large, complex applications built from smaller, reusable components. These interacting elements contribute significantly to the versatility and power of Wasm, enabling it to perform tasks from high-performance computing to dynamic generation of web content. This makes Wasm an essential part of the modern web platform and a valuable tool for the IoT space.

2.3. WebAssembly Binary Format

2.4. How Does WebAssembly Complement JavaScript?

• Performance Enhancement: JavaScript is the traditional language used in web development, and is known for its versatility and ease of use. However, JavaScript is an interpreted language, which can sometimes result in slower execution compared to lower-level languages such as C and C++. By leveraging Wasm, developers can offload computationally intensive tasks to the Wasm module, resulting in improved performance and responsiveness.
• Language Compatibility: JavaScript has a vast ecosystem of libraries, frameworks, and tools that have been developed over the years. It is the language of the web, and many developers are already familiar with it. Wasm, on the other hand, supports multiple programming languages, including C/C++, Rust, and more. This means that developers can utilize their existing codebase written in different languages and compile it to Wasm to run in the browser. This enables developers to reuse and integrate existing code with JavaScript seamlessly.
• Code Portability: JavaScript is supported by all modern web browsers, making it highly portable. However, there are cases in which certain algorithms or complex computations are more efficiently implemented in lower-level languages. With Wasm, developers can compile code from these languages into Wasm modules, which can then be executed in any web browser that supports Wasm. This portability allows developers to target multiple platforms without the need for language-specific implementations.
• Security and Isolation: JavaScript executes within the browser’s sandbox environment, which provides a level of security by preventing direct access to the underlying system resources. Wasm runs within a sandboxed environment as well; however, it provides additional security features such as memory isolation and fine-grained control over resource access. By utilizing Wasm, developers can ensure a higher level of security when executing potentially untrusted code.
• Extending JavaScript’s Capabilities: Wasm can be used as a complementary technology to extend JavaScript’s capabilities. Developers can leverage Wasm modules to perform computationally intensive tasks, data processing, or even run existing software libraries. JavaScript can act as a glue language, interacting with Wasm modules and providing a higher-level interface or handling UI-related tasks.
• Improved Developer Experience: Wasm and JavaScript work hand in hand to enhance the developer experience. Developers can utilize their preferred language for different parts of the application, choosing JavaScript for UI interactions, DOM manipulation, and event handling while offloading performance-critical or complex computations to Wasm modules. This division of labor allows developers to write cleaner and more maintainable code and to optimize performance where it matters most.

2.5. Why WebAssembly Is a Good Fit for Web Platforms

2.6. Web Embedding

2.7. Non-Web Embeddings

2.8. Portability

2.9. Interoperability of Wasm

• Interaction with JavaScript
  Wasm is designed to complement and work side-by-side with JavaScript. Wasm modules can be loaded and executed from JavaScript, allowing developers to run complex computations using Wasm while leveraging JavaScript for less performance-sensitive tasks. This interaction between JavaScript and Wasm is facilitated by the Wasm JavaScript API, which includes functions to compile and instantiate Wasm modules. Furthermore, Wasm and JavaScript can share data using Wasm’s linear memory, a contiguous and resizable array of bytes that JavaScript can read from and write to. This shared memory model allows for efficient communication between Wasm and JavaScript, enabling complex applications that utilize the strengths of both languages.
• FFI
  The FFI is a mechanism through which a program written in one programming language can call routines or make use of services written in another [14,15]. FFI is used when two languages do not share a common interface or when they cannot interact directly with each other. Wasm utilizes an FFI to enable interoperability with JavaScript and other programming languages. Through the FFI, Wasm can call functions written in JavaScript and vice versa. This is critical because it allows Wasm to leverage the extensive ecosystem of JavaScript libraries and the broader web platform. The FFI plays a significant role in Wasm’s integration with other languages in non-web contexts as well. Languages such as Rust, Go, and C/C++ can compile to Wasm and interact with other systems or libraries through the FFI. This interaction is critical for many use cases, especially when it comes to system-level programming in fields such as IoT. However, working with the FFI can be quite complex due to the difference in memory models between Wasm and other languages. Wasm’s linear memory model is different from the models used by most programming languages, and translating between the two can be challenging. Solutions such as the Wasm Interface Types proposal are aimed at making this easier, and interoperation between Wasm and other languages is expected to become more seamless as these improvements are adopted.
• Access to Web APIs
  Wasm can indirectly access various web APIs through JavaScript. While Wasm cannot directly call web APIs, it can call JavaScript functions that can interact with these APIs. This model provides a layer of abstraction that enhances security while enabling the rich functionality that web APIs offer. In the future, with the integration of the Wasm Interface Types proposal, Wasm modules will be able to directly interact with web APIs, enhancing its interoperability and functionality.
• Compatibility Across Browsers
  Wasm modules are designed to be portable, meaning that they can run on any platform that provides a compliant Wasm virtual machine. This includes all modern web browsers (Google Chrome, Mozilla Firefox, Safari, and Edge). This cross-browser compatibility ensures that a Wasm module developed on one platform can run seamlessly on another, enhancing the reach and usability of web applications built with Wasm.
• Use in Non-Web Environments
  Although Wasm was designed for the web, properties such as its compact binary format, sandboxed execution environment, and deterministic behavior make it an attractive option for non-web environments as well, including IoT devices, edge computing, and serverless computing. Wasm modules can be run outside of a web browser using a runtime such as Wasm System Interface (WASI), further enhancing its interoperability. This broad interoperability of Wasm in terms of working with other web technologies and compatibility across a wide range of platforms is one of its key strengths. As Wasm continues to evolve its interoperability is likely to expand, further increasing its potential use cases and influence in the web development and IoT ecosystems.

2.10. Interfacing with the Host Environment

• How WebAssembly Interacts with the Host
  Wasm modules are designed to be embedded within a host environment, which in most cases is a web browser [16]. A Wasm module cannot interact with the host environment directly; instead, it must interact through JavaScript using a set of explicit imports and exports. This mechanism allows Wasm to interact with JavaScript APIs, access the Document Object Model (DOM), and more, all while maintaining a clear boundary between the Wasm module and the host environment.
• Web APIs and JavaScript Glue Code
  To interact with web APIs, Wasm relies on JavaScript “glue” code that serves as an intermediary. This glue code can call web APIs and pass the results back to the Wasm module. This mechanism allows Wasm to take advantage of the wide range of APIs available on the web, such as those for accessing hardware capabilities, networking, storage, and more.
• WebAssembly JavaScript API
  Wasm provides its own JavaScript API, which is used to load, compile, and instantiate Wasm modules. This API allows developers to interact with Wasm directly from their JavaScript code, providing a high degree of control over the lifecycle of Wasm modules.
• Direct DOM Access
  While Wasm cannot currently access the DOM directly, and must rely on JavaScript, there is an ongoing proposal to add direct DOM access to Wasm. This would allow Wasm to manipulate the DOM without having to go through JavaScript, potentially leading to performance improvements for certain types of applications.
• Beyond the Browser
  While the primary host environment for Wasm is the web browser, it is not limited to this context. Wasm can be hosted in non-web environments, for instance, standalone runtimes such as Wasmer and Wasmtime, or embedded in other applications. This flexibility makes Wasm an appealing choice for a variety of use cases, from server-side applications to IoT devices and more.

2.11. The Security Model of WebAssembly

• User Protection
  Wasm modules operate within a secure sandbox environment that uses fault isolation techniques to separate them from the host runtime. This ensures the following:

  –

  Applications run independently within the sandbox, and cannot escape without using appropriate APIs.

  –

  Deterministic execution is generally maintained, with limited exceptions.

  –

  Modules adhere to the security policies of their embedding. In web browsers, this includes restrictions imposed by the same-origin policy, while other platforms may have their own security models.

• Developer Support
  Wasm’s design focuses on supporting the development of secure programs by eliminating dangerous features from its execution semantics while remaining compatible with C/C++ code.

  –

  Modules must declare all accessible functions and associated types during load time, even when utilizing dynamic linking. This enables implicit control-flow integrity through structured control flow. Immutable compiled code and lack of runtime observability protect Wasm programs from control flow hijacking attacks.

  –

  Function calls within Wasm must specify valid target indices that correspond to entries in the function index space or table index space.

  –

  Indirect function calls undergo runtime type signature checks, ensuring that the selected function matches the expected signature.

  –

  The use of a protected call stack prevents buffer overflows in the module heap and ensures safe function returns.

  –

  Branches within functions must point to valid destinations within the same function.

  –

  Variables in C/C++ are represented using primitives in Wasm, depending on their scope. Local variables with fixed scope and global variables are stored as fixed-type values indexed by their respective indices. Local variables are initialized to zero and stored in the protected call stack, while global variables reside in the global index space and can be imported from external modules. Local variables with uncertain static scope are stored in a separate user-addressable stack in linear memory during compilation. Bounds checking is performed at the region level to prevent out-of-bounds accesses. Future enhancements may include support for multiple memory sections and more advanced memory operations.

  –

  Traps are used to immediately terminate execution and signal abnormal behavior. They are triggered by operations such as invalid index access, mismatched type signature in indirect function calls, exceeding the maximum size of the protected call stack, out-of-bounds linear memory access, or illegal arithmetic operations.

• Memory Safety
  Wasm’s execution semantics mitigate certain memory safety issues compared to traditional C/C++ programs. Local and global variables stored in the index space are protected from buffer overflows due to their fixed sizes and indexed addressing. Linear memory accesses are checked at the region level, preventing out-of-bounds access. However, control-flow integrity and the protected call stack prevent direct code injection attacks. Hence, mitigations such as data execution prevention and stack smashing protection are unnecessary for Wasm programs. However, certain types of bugs are not obviated by Wasm’s semantics. Control flow hijacking attacks can manipulate module control flow using code reuse attacks against indirect calls. Nevertheless, common techniques such as return-oriented programming are not possible in Wasm due to enforced control-flow integrity. Additionally, race conditions, side channel attacks, and time of check to time of use vulnerabilities can occur. Future enhancements may provide additional protections such as code diversification, memory randomization, or bounded pointers.
• Control-Flow Integrity
  Control-flow integrity is crucial for measuring security effectiveness. Wasm provides implicit guarantees for direct function calls through function section indexes and for returns through the protected call stack. Indirect function calls undergo runtime type checks to ensure coarse-grained control-flow integrity. Fine-grained control-flow integrity can be achieved through the use of the Clang/low level virtual machine (LLVM) compiler infrastructure, which offers built-in support for Wasm.
• Clang/LLVM CFI
  Enabling fine-grained control-flow integrity (CFI) using the Clang/LLVM compiler has several advantages. It provides enhanced defense against code reuse attacks involving indirect function calls, and performs function signature checks at the C/C++ type level. Although enabling this feature incurs a slight performance cost for each indirect call, future updates will optimize it by leveraging built-in support for multiple indirect tables.
• Code Validation and Verification
  Wasm implements a two-step validation process to ensure the safety of its modules. The first step involves structural validation to check whether the module follows the binary format specification. The second step includes control flow and type checking to ensure that the code is well-structured and does not perform illegal operations.
• Safe Interoperability with JavaScript
  Considering that Wasm is designed to work alongside JavaScript in the same web environment, it is crucial to ensure safe interoperability between the two. Wasm modules can interact with JavaScript through a set of explicit exports and imports, allowing for controlled interaction between the two. By strictly defining these interfaces, Wasm ensures that the security of the web platform is preserved.

3.1. Why WebAssembly for IoT?

• Performance Efficiency
  Wasm, designed as a low-level binary format, delivers near-native performance, an essential consideration for IoT devices as they are often constrained by limited resources. The fast downloading, efficient parsing, and swift execution times offered by Wasm contribute to reduced latency, a significant requirement in real-time IoT applications. The IoT landscape is characterized by a multitude of interconnected devices, and these are often constrained by computational resources while needing to perform tasks efficiently and quickly. Wasm’s performance efficiency presents a significant advantage in this context.

  –

  Near-Native Speed

  At its core, Wasm is a low-level binary format designed to be decoded and executed at near-native speed. Unlike traditional web scripting languages such as JavaScript, which are parsed and executed at runtime, Wasm is a compiled binary, allowing it to run much faster. This speed is of paramount importance in IoT environments where real-time processing is often required.

  –

  Resource Optimization

  Wasm’s binary format is designed to be both small in size and fast to parse, leading to a reduction in the required amount of resources. This makes it particularly suitable for IoT devices, which often have limited memory and processing power. Reduced binary size means less storage space and quicker download times, while faster parsing leads to improved execution speed, both of which are crucial to the performance optimization of IoT applications.

  –

  Concurrent and Parallel Processing

  Wasm is designed to support concurrent and parallel processing. It enables multi-threading capabilities using Web Workers in the web environment. This means that Wasm can execute instructions on multiple cores simultaneously, making it even more efficient for computationally intensive tasks. This feature can be highly beneficial for IoT environments in which tasks need to be performed in parallel, and can improve the overall performance of the system.

  –

  Stream Compilation and Tiered Compilation

  Wasm benefits from stream compilation, meaning it can be compiled and optimized while being downloaded. This leads to faster startup times, and becomes crucial in IoT scenarios, where quick application startup can be critical. In addition, modern Wasm engines use tiered compilation, a technique where the code is first compiled and optimized for speed, then re-optimized during execution for improved overall performance.

  –

  Optimized Execution Environment

  Wasm runs within a highly optimized execution environment which is designed to utilize the capabilities of modern CPUs to the fullest extent. It can take advantage of common hardware capabilities and processor features, further boosting execution speed. This is particularly useful for IoT devices, where the computational capabilities of the device need to be used efficiently.

• Flexibility
  Wasm’s platform-agnostic nature adds flexibility to IoT development, enabling the same code to run across multiple devices and platforms. This universal compatibility eliminates the need for platform-specific adaptations, reducing development time and effort, which is critical in fast-evolving IoT ecosystems. Wasm’s design as a platform-agnostic bytecode provides a high degree of portability and flexibility, particularly beneficial in the diverse landscape of IoT. This section delves into the aspects that make Wasm’s portability and flexibility a critical advantage for IoT applications.

  –

  Platform-Agnostic Nature

  Wasm is designed to be platform-agnostic. It can be run on any device with a compliant Wasm runtime, irrespective of the underlying hardware or operating system. This portability is especially critical in IoT, where a wide range of devices need to be programmed, from small sensors to large industrial machines. Developers can write code once and run it on any IoT device, reducing the time, effort, and cost of development.

  –

  Language Independence

  Wasm allows developers to work in multiple high-level programming languages. At present, languages such as C/C++, Rust, and AssemblyScript can be compiled to Wasm. This means developers can choose the language that best suits their use case or expertise, adding to the flexibility of the development process.

  –

  Interoperability with JavaScript

  Despite being an independent format, Wasm is designed to be highly interoperable with JavaScript. It can leverage the existing web platform and interact seamlessly with JavaScript APIs. This attribute is essential in IoT contexts, where Wasm and JavaScript can be used interchangeably or together within the same application, enabling a highly flexible and adaptive development approach.

  –

  Resource Efficiency

  The binary nature of Wasm enables smaller file sizes, leading to faster downloads and reduced network overhead. This is particularly beneficial in IoT environments, where network bandwidth can be constrained and devices have limited storage and processing power.

  –

  Evolving Ecosystem

  The ecosystem around Wasm, including tools, libraries, and runtime environments, is continuously evolving and improving. This evolving ecosystem enables developers to leverage new features and enhancements over time, adding to the flexibility and adaptability of Wasm in the IoT context.

• Compactness and Energy Efficiency
  Wasm’s compact binary format allows smaller payloads over network communication, making it ideal for IoT networks, where bandwidth may be limited. Furthermore, the efficiency of Wasm execution can contribute to lower energy consumption in battery-powered IoT devices. Wasm’s compact design and energy-efficient execution make it a particularly attractive technology for IoT applications, which often involve resource-constrained devices operating in environments where power supply may be limited or intermittent. This section, explores how Wasm’s compactness and energy efficiency contribute to its suitability for IoT.

  –

  Compactness and Efficient Execution

  Wasm, as a low-level binary format, is far more compact than traditional text-based languages. This compactness has several implications:

  *

  First, smaller binary sizes mean faster transmission over networks, an essential attribute for IoT devices that often rely on low-bandwidth networks.

  *

  Second, small binary size leads to less memory usage on devices, an important aspect considering many IoT devices operate with limited memory.

  *

  Lastly, because Wasm is a low-level bytecode, it requires fewer processing cycles to execute than high-level languages, resulting in more efficient execution. These characteristics collectively enable Wasm applications to be faster and more responsive, which is especially important in real-time IoT applications.

  –

  Energy Efficiency

  Energy efficiency is a critical factor in the IoT landscape, where devices are often battery-powered or need to operate in energy-efficient modes. The execution efficiency of Wasm contributes to reduced power consumption. As a binary instruction set, Wasm is processed directly by the device, eliminating the need for resource-intensive operations such as parsing or bytecode interpretation. This efficiency results in lower CPU usage, which in turn leads to reduced energy consumption.

  –

  Reducing Network Load

  The compactness of Wasm results in less network load, as smaller file sizes require less bandwidth to transmit. This is a significant advantage in IoT environments, where network bandwidth may be a scarce resource. By reducing the amount of data that needs to be transmitted, Wasm can contribute to overall energy savings in IoT networks.

  –

  Support for Energy-Efficient Programming Paradigms

  Wasm’s support for languages such as Rust, which emphasizes zero-cost abstractions and fine-grained control over system resources, allows for energy-efficient programming paradigms. Developers can optimize their code to manage resources effectively and minimize energy consumption, which is crucial for power-constrained IoT devices.

3.2. WebAssembly Support for IoT Programming

3.3. WebAssembly and IoT Security

• Secure Sandboxing
  One of the central features of Wasm is that it runs in a secure sandbox environment [18]. This means that the Wasm code execution is isolated from the rest of the system, preventing it from engaging in uncontrolled interactions with other parts of the system. This feature is critical in the IoT context, where devices are often connected to public networks, where they are vulnerable to various kinds of attacks. By confining each Wasm module to its sandbox, the damage an attacker can cause is limited.
• Controlled Interactions with the Host Environment
  In Wasm, all interactions with the host environment must be explicitly defined through imports and exports. This means that a Wasm module can only access the host resources that it has been explicitly granted access to. This capability provides a strong isolation between the Wasm module and the host system, limiting the potential attack surface and reducing the risk of unauthorized access to sensitive resources, a particularly desirable trait for IoT applications.
• Verification and Validation
  Wasm modules undergo a validation process before execution. This validation ensures that the module adheres to the Wasm specification and is free of certain types of errors, further enhancing its security. Moreover, certain Wasm compilers, such as those used in the Rust ecosystem, offer even more robust validation and verification processes, further enhancing the security of IoT applications.
• Secure IoT Applications with WebAssembly
  The security features offered by Wasm are not merely theoretical; they are being actively leveraged in real-world IoT applications. For instance, edge computing applications, which require processing data close to the source, often utilize Wasm for its secure execution environment. Similarly, industrial IoT solutions benefit from the security and isolation features of Wasm when dealing with critical infrastructure components.
• Future Directions in WebAssembly and IoT Security
  While Wasm already brings significant security benefits to IoT, the technology continues to evolve, and future enhancements may further bolster these security credentials. Initiatives such WASI aim to define a secure and portable interface for Wasm modules, broadening their applicability beyond the web browser while maintaining robust security guarantees. As IoT continues to expand and evolve, the security capabilities of technologies such as Wasm can be expected to evolve alongside.

3.4. WebAssembly and IoT Performance Optimization

• Fast Execution Speed
  Wasm is designed to offer near-native performance, which is crucial for IoT devices that often have to process complex tasks within strict time constraints. With its efficient binary format, Wasm instructions can be executed quickly and effectively, which results in faster application performance. This speed is particularly valuable in IoT environments, where real-time data processing can be critical.
• Efficient Use of Memory
  Wasm implements a linear memory model, which means all memory is managed in a single, contiguous block. This approach reduces memory fragmentation and allows more efficient memory usage. Furthermore, Wasm’s compact binary format requires less memory for code storage. These memory management practices can greatly benefit IoT devices, which often operate with limited memory.
• Streamlined Parsing and Compilation
  Wasm’s binary format is designed to be fast to parse and compile. Compared to traditional text-based languages, binary formats are significantly quicker to process. This feature can greatly speed up the time from fetching the code to executing it, an important factor in IoT devices, as they often need to start quickly and perform their tasks in real-time.
• Parallelism and Concurrency
  Wasm is designed with parallelism and concurrency in mind. With the proposal of Wasm threads, developers can leverage multicore processors more effectively by parallelizing their computations. This feature can be especially beneficial in the IoT context, where devices equipped with multi-core processors can utilize Wasm to run computationally intensive tasks more efficiently.
• Performance in Real-world IoT Applications
  Wasm’s performance features are not just theoretical; they have practical implications in the world of IoT. For instance, in edge computing, where latency is a critical factor, Wasm’s fast execution speed and efficient memory usage can greatly improve application responsiveness. Similarly, in the realm of smart devices and wearables, where battery life and responsiveness are crucial, the efficient use of resources that Wasm allows can lead to significant improvements.

3.5. WebAssembly and IoT Networking

• Cross-platform Communication
  One of the challenges in IoT networking is the heterogeneous nature of IoT devices. They can have different operating systems, architectures, and capabilities. Wasm, with its cross-platform nature, can help to bridge these differences. Regardless of the device’s specific hardware or operating system, a Wasm module can run on any device with a compliant Wasm runtime. This provides a common platform that can facilitate communication and data exchange across diverse devices.
• Efficient Data Transfer
  Wasm’s compact binary format facilitates efficient execution while contributing to efficient data transfer. Compared to traditional text-based code, Wasm’s binary format is smaller and quicker to load, which can result in less network usage and faster transfer speeds. This is particularly important in IoT networks, which can involve the transfer of large amounts of data.
• Secure Communication
  Security is a paramount concern in IoT networks due to the potentially sensitive nature of the data being transferred. Wasm contributes to secure communication in number of ways:

  –

  Wasm operates within a sandboxed environment, meaning that it is isolated from the rest of the system, helping to contain any potential security threats.

  –

  Wasm is designed to be integrated with existing web platform security mechanisms, meaning that it can leverage features such as HTTPS for secure data transfer.

• Real-time Communication
  Many IoT applications require real-time or near-real-time communication. Whether a security system detecting an intruder or a health monitor tracking a patient’s vitals, quick and responsive communication can be critical. Wasm’s efficient execution and fast parsing can help to facilitate this kind of real-time communication.
• WebAssembly Networking in Real-world IoT Applications
  Wasm’s networking features are being leveraged in various IoT applications. For instance, in the realm of smart home devices Wasm can facilitate efficient and secure communication between devices, including lighting systems, thermostats, and security cameras. In industrial IoT, Wasm can enable real-time monitoring and control of equipment across a network.

3.6. Practical Applications of WebAssembly in IoT

• Edge Computing
  Edge computing refers to the paradigm of processing and analyzing data at or near the edge devices in an IoT network, rather than relying solely on centralized cloud infrastructure. By moving computational tasks closer to the data source, edge computing enables real-time processing, reduced latency, improved privacy, and bandwidth optimization. Wasm has emerged as a promising technology for practical applications in IoT edge computing environments.

  –

  One of the key advantages of Wasm in the context of IoT is its ability to execute efficiently on resource-constrained edge devices. IoT devices often have limited computational power, memory, and battery life, making it challenging to run complex applications directly on the devices. Wasm’s compact binary format and efficient execution enable the deployment of lightweight and high-performance applications on IoT devices. This allows for the offloading of computational tasks from cloud servers to the edge, reducing network traffic and enabling faster response times.

  –

  Wasm’s security features play a significant role in IoT edge computing. With the sandboxed execution environment provided by Wasm, the risk of malicious code execution or unauthorized access to sensitive data is mitigated. This is crucial in the context of IoT, where devices may be vulnerable to security threats. Wasm’s security model ensures that only authorized and verified code can be executed on edge devices, enhancing the overall security posture of the IoT ecosystem.

  –

  In practical applications, Wasm in IoT edge computing can enable a wide range of use cases. For instance, it can facilitate real-time analytics and decision-making at the edge by running machine learning algorithms for sensor data processing, anomaly detection, and predictive maintenance. Wasm’s low latency execution allows for immediate response to critical events and minimizes the need for constant communication with the cloud.

  –

  Additionally, Wasm can enable edge devices to interact with existing web technologies and APIs. This allows developers to leverage the vast ecosystem of web-based tools, libraries, and frameworks for building IoT applications. Wasm’s interoperability with JavaScript and other web languages further simplifies the integration of edge devices into larger IoT systems.

  –

  Moreover, the flexibility of Wasm makes it suitable for dynamic edge computing environments. The ability to dynamically load and update Wasm modules on edge devices enables the deployment of over-the-air updates, application customization, and remote management of IoT deployments. This dynamic nature of Wasm empowers IoT systems with greater adaptability and scalability.

• Smart Home Devices
  Smart home devices in which various devices are interconnected and communicate with each other to create intelligent and automated living spaces play a crucial role in the IoT ecosystem. Wasm technology offers practical applications in enhancing the capabilities and performance of smart home devices within the IoT framework. There are a number of practical benefits to using Wasm in smart home devices:

  –

  Efficient and Fast Execution

  Wasm allows smart home devices to execute code with near-native performance. By compiling code into a compact and efficient binary format, Wasm enables smart home devices to perform complex tasks and computations quickly, resulting in improved responsiveness and overall user experience.

  –

  Cross-platform Compatibility

  Wasm provides a platform-independent execution environment, enabling smart home devices to run the same code across various operating systems and hardware architectures. This compatibility allows developers to build applications and services that work seamlessly on different devices, reducing development efforts and ensuring broader device support.

  –

  Enhanced Security

  Security is a critical aspect of smart home devices, and Wasm contributes to strengthening device security. With its sandboxed execution environment, Wasm ensures that malicious code cannot access or manipulate sensitive data within the smart home device. This protection layer helps to prevent unauthorized access and safeguard user privacy.

  –

  Extensibility and Flexibility

  Wasm allows developers to extend the functionalities of smart home devices by easily integrating third-party libraries and modules. This extensibility empowers developers to leverage existing libraries and tools to enhance the capabilities of smart home devices without having to rewrite the entire codebase, and promotes the creation of a vibrant ecosystem of reusable components and modules for smart home applications.

  –

  Offline and Edge Computing

  Smart home devices often operate in environments with intermittent or limited internet connectivity. Wasm enables the execution of code offline and supports edge computing scenarios, where computation is performed locally on the device rather than relying solely on cloud services. This capability ensures that smart home devices can continue functioning even in situations where internet access is unavailable or unreliable.

  –

  User Interface and Interactivity

  Wasm allows developers to create rich and interactive user interfaces for smart home devices. By leveraging web technologies such as HTML, CSS, and JavaScript, developers can design intuitive and visually appealing interfaces that enable users to seamlessly control and monitor their smart home devices. This flexibility in user interface design enhances the overall user experience and makes smart home devices more accessible to a wider range of users.

  –

  Over-the-Air Updates

  Wasm facilitates over-the-air updates for smart home devices, allowing manufacturers to efficiently deliver software updates and bug fixes. With Wasm, updates can be delivered in a modular and incremental manner, reducing the impact on device performance and minimizing downtime. This capability ensures that smart home devices can benefit from the latest features, security patches, and improvements without requiring manual intervention.

• Industrial IoT
  The Industrial Internet of Things (IIoT) refers to the use of interconnected devices and systems in industrial environments, such as manufacturing plants, factories, and industrial facilities. Wasm technology has practical applications in enhancing the capabilities and efficiency of IIoT systems. There are several ways in which Wasm can be applied in the IIoT context:

  –

  Real-time Data Processing

  IIoT systems generate a vast amount of sensor data in real time. Wasm enables efficient and high-speed data processing by executing code closer to the edge. With its near-native performance, Wasm can process and analyze data streams rapidly, facilitating real-time decision-making and automation in industrial processes.

  –

  IIoT Edge Computing

  In IIoT applications, low-latency processing is essential for time-critical operations. Wasm enables edge computing by allowing computations to be performed directly on edge devices or gateways. This reduces the dependency on cloud services and enables faster response times, making IIoT systems more resilient and efficient.

  –

  Compatibility and Interoperability

  Wasm’s platform-independent nature makes it an ideal technology for achieving compatibility and interoperability in IIoT environments. It enables seamless execution of the same code across different devices, operating systems, and hardware architectures, facilitating the integration of diverse systems and components in industrial settings.

  –

  Security and Safety

  Industrial environments require robust security measures to protect critical infrastructure and sensitive data. Wasm enhances the security of IIoT systems by providing a sandboxed execution environment that isolates code execution and prevents unauthorized access or tampering. This helps in safeguarding industrial processes, ensuring data integrity, and mitigating potential cybersecurity threats.

  –

  Legacy System Integration

  Many industrial facilities rely on legacy systems and equipment that may not natively support modern technologies. Wasm enables the integration of legacy systems by providing a bridge between old and new technologies. By compiling legacy code into Wasm modules, industrial organizations can leverage the benefits of IIoT without the need for a complete system overhaul.

  –

  Remote Monitoring and Control

  IIoT systems often involve remote monitoring and control of industrial processes. Wasm enables the development of lightweight and efficient web-based user interfaces that can be accessed from anywhere using standard web browsers. This allows remote operators and engineers to monitor real-time data, control industrial equipment, and make informed decisions remotely, improving operational efficiency and reducing downtime.

  –

  Offline Operation and Fault Tolerance

  Industrial environments may experience network disruptions or operate in remote areas with limited connectivity. Wasm enables IIoT systems to operate offline or with intermittent connectivity by executing code locally on edge devices. This ensures uninterrupted operation, data logging, and fault tolerance even in challenging network conditions.

  –

  Customization and Modularity

  Wasm’s modular architecture enables the creation of customized IIoT applications by combining pre-built modules and components. This promotes code reusability, accelerates development cycles, and allows for the creation of tailored solutions that address specific industrial requirements. It facilitates easy maintenance and updates by enabling modular replacement or addition of functionality.

• Wearable Devices
  Wearable devices have gained significant popularity in recent years, offering various functionalities and improving the way we monitor and interact with our health, fitness, and daily activities. With the emergence of Wasm, these wearable devices can benefit from its practical applications in the IoT ecosystem. There are a number of ways in which Wasm can be applied in the context of wearable devices:

  –

  Enhanced Performance

  Wasm enables wearable devices to efficiently execute computationally intensive tasks. By leveraging near-native performance, Wasm can handle complex algorithms and data processing tasks, providing a seamless user experiences without compromising battery life or device performance. This allows wearable devices to perform tasks such as real-time health monitoring, fitness tracking, and advanced data analysis without significant lag or slowdown.

  –

  Cross-platform Compatibility

  Wasm’s platform-independent nature makes it an ideal technology for developing wearable applications that can run across different operating systems and hardware platforms. This cross-platform compatibility ensures that wearable devices can offer consistent functionality and user experiences regardless of the device or operating system being used. Developers can write code once and deploy it on multiple wearable platforms, saving time and effort in application development.

  –

  Offline Functionality

  Wearable devices often operate in situations where internet connectivity may be limited or unreliable. Wasm enables offline functionality by allowing key application components to run locally on the wearable device. This ensures that critical functionalities such as heart rate monitoring or step counting can continue even when the device is not connected to the internet or a smartphone. Offline functionality enhances the usability and reliability of wearable devices in various scenarios.

  –

  Customizable User Interfaces

  Wasm empowers developers to create customized user interfaces for wearable devices. With its ability to integrate with web technologies, Wasm allows for the development of interactive and dynamic user interfaces that can adapt to different screen sizes and input methods. This enables wearable devices to provide intuitive and personalized user experiences, enhancing user engagement and satisfaction.

  –

  Secure Data Processing

  Data security and privacy are crucial considerations in wearable devices, especially when handling personal health and fitness information. Wasm’s sandboxed execution environment provides an additional layer of security by isolating code execution from the underlying system. This helps to protect sensitive data and prevent unauthorized access or tampering, ensuring the confidentiality and integrity of user information.

  –

  Connectivity and Interoperability

  Wearable devices often interact with other IoT devices, smartphones, or cloud services to provide a comprehensive user experience. Wasm facilitates seamless connectivity and interoperability by allowing wearable devices to communicate with other devices through standardized web APIs. This enables data sharing, synchronization, and integration with companion apps or cloud platforms, enhancing the functionality and versatility of wearable devices.

  –

  Efficient Application Updates

  Wasm simplifies the process of updating wearable device applications. With Wasm, developers can deliver updates by sending optimized binary modules that can be quickly downloaded and executed on the device. This eliminates the need for time-consuming app store updates and enables wearable devices to receive the latest features and bug fixes promptly.

  –

  Extendable Functionality

  Wearable devices often have limited resources and storage capacity. Wasm’s modular architecture allows developers to create extensible applications by leveraging pre-built modules and components. This enables wearable device manufacturers to provide additional functionalities through modular upgrades, such as adding new sensors or integrating with third-party services, without the need for significant hardware changes or device replacements.

• IoT Gateways
  IoT gateways play a critical role in the practical implementation of Wasm in the IoT ecosystem. These gateways act as intermediaries between IoT devices and the cloud or edge infrastructure, facilitating seamless communication, data processing, and management. There are a number of ways in which Wasm can be applied in the context of IoT gateways:

  –

  Protocol Translation

  IoT gateways often need to support multiple communication protocols to interact with a diverse range of IoT devices. Wasm can be leveraged to implement protocol translation layers within the gateway. The gateway can efficiently convert data between different protocols using Wasm modules, ensuring compatibility and interoperability among various IoT devices and systems. This enables seamless integration of devices that use different communication standards, such as MQTT, CoAP, Zigbee, and Bluetooth.

  –

  Edge Computing and Data Processing

  IoT gateways act as the edge computing nodes, bringing computational capabilities closer to the IoT devices and reducing latency. Wasm can be utilized within the gateway to execute compute-intensive tasks and perform data processing at the edge. By running Wasm modules on the gateway, critical data analysis, filtering, or aggregation can be performed locally, reducing the need to transmit large volumes of raw data to the cloud. This improves response time while minimizing bandwidth consumption and cloud infrastructure costs.

  –

  Security and Access Control

  Wasm enhances the security of IoT gateways by providing a sandboxed execution environment for executing untrusted code. This allows the gateway to execute Wasm modules securely, isolating them from the underlying operating system and protecting the gateway from potential vulnerabilities or malicious code. Additionally, Wasm enables the implementation of access control policies, ensuring that only authorized modules can be executed on the gateway and granting specific permissions based on the module’s trust level.

  –

  Gateway Management and Orchestration

  Wasm can be leveraged in the management and orchestration of IoT gateways. Thanks to its modular and lightweight nature, Wasm modules can be used to implement gateway management functionalities such as configuration management, firmware updates, and remote monitoring. These modules can be dynamically loaded, enabling flexible and efficient gateway management without the need for complex software updates or downtime.

  –

  Offline Operation and Local Decision Making

  IoT gateways often operate in environments with intermittent or unreliable internet connectivity. Wasm enables the gateway to operate offline by executing critical logic and decision-making processes locally. By running Wasm modules on the gateway, it can continue to function autonomously even when disconnected from the cloud or experiencing network disruptions. This ensures that essential operations such as real-time control, event processing, and local data analytics can be performed without relying on constant internet connectivity.

  –

  Intelligent Edge Analytics

  Wasm allows IoT gateways to perform advanced analytics and machine learning tasks at the edge. By executing Wasm modules that incorporate pre-trained models or algorithms, the gateway can analyze sensor data in real time, identify patterns, detect anomalies, and derive valuable insights locally. This enables timely and intelligent decision-making at the edge, reducing the need to transmit raw data to the cloud for analysis and enabling faster response times for critical applications.

  –

  Scalability and Flexibility

  Wasm offers scalability and flexibility in IoT gateway deployments. The modular nature of Wasm allows developers to build and deploy custom functionalities and services as lightweight modules. These modules can be dynamically loaded or unloaded on the gateway, enabling easy customization and scalability based on specific use cases or changing requirements. Wasm’s ability to run across different hardware architectures and operating systems further enhances the flexibility and compatibility of IoT gateway deployments.

  –

  Over-the-Air Updates

  Wasm simplifies the process of updating IoT gateway applications and functionalities. By delivering optimized Wasm binary modules, developers can perform over-the-air updates on the gateway, allowing seamless deployment of new features, bug fixes, and security patches without interrupting device operation. This ensures that the gateway remains up-to-date with the latest capabilities and improvements, enhancing the overall performance and security of the IoT ecosystem. Table 2 presents a comparison of practical applications in the context of Wasm in IoT.

4.1. WebAssembly Compilers

• Emscripten
  Emscripten is a popular compiler toolchain that enables the translation of C/C++ code into Wasm, allowing developers to run code written in these languages on the web [19].

  –

  Pros

  *

  Wide adoption and active community support

  *

  Provides high compatibility with existing C/C++ codebases

  *

  Offers integration with popular web frameworks and libraries and provides advanced optimization options

  –

  Cons

  *

  Requires a more substantial toolchain setup and configuration

  *

  Compilation process can be slower compared to other compilers

  *

  Code output can be larger in size, impacting load times

• TinyGo
  The TinyGo is a compiler is specifically designed to compile Go code into Wasm [20]. It aims to provide a minimal and efficient Go runtime for running Go applications in resource-constrained environments.

  –

  Pros

  *

  Produces small Wasm binaries optimized for size and speed

  *

  Provides good compatibility with the Go programming language

  *

  Supports direct interaction with JavaScript APIs, offering a lightweight and fast compilation process

  –

  Cons

  *

  Limited support for certain Go language features and standard library packages

  *

  Less mature compared to other Go compilers

  *

  Smaller ecosystem and community compared to mainstream Go

• WARDuino
  WARDuino is a compiler that targets the Arduino platform, allowing developers to write programs in a subset of the C language and compile them to run on Arduino devices [21].

  –

  Pros

  *

  Enables developers to write Arduino programs using a higher-level language

  *

  Provides abstraction and simplification for Arduino programming Offers compatibility with Arduino libraries and hardware

  –

  Cons

  *

  Limited to Arduino-specific use cases

  *

  Less support for advanced features compared to general-purpose compilers

  *

  Requires familiarity with the Arduino platform

• wasm3
  Wasm3 is a lightweight Wasm runtime and interpreter that allows Wasm modules to be run efficiently [22]. It is designed for resource-constrained environments and has a small footprint.

  –

  Pros

  *

  Lightweight and efficient runtime suitable for embedded systems and IoT devices

  *

  Provides fast startup and execution times

  *

  Supports multiple Wasm language bindings

  –

  Cons

  *

  Limited support for some advanced Wasm features

  *

  Lacks extensive tooling and development ecosystem compared to larger runtimes

  *

  Limited support for interacting with host environments

• AssemblyScript
  AssemblyScript is a programming language similar to TypeScript that is designed to compile to Wasm [23]. It allows developers to write high-level code that compiles to efficient Wasm modules.

  –

  Pros

  *

  Familiar syntax and tooling for TypeScript developers

  *

  Provides type safety and high-level abstractions

  *

  Offers seamless integration with JavaScript code and libraries

  *

  Generates efficient Wasm modules

  –

  Cons

  *

  Limited support for advanced JavaScript features

  *

  Less mature compared to mainstream programming languages

  *

  Smaller community and ecosystem compared to other languages

• wasmino-core
  Wasmino-core is a compiler and runtime for Wasm modules specifically designed for running Wasm on resource-constrained microcontrollers [24].

  –

  Pros

  *

  Optimized for microcontrollers and embedded systems

  *

  Provides a lightweight runtime with a small memory footprint

  *

  Supports C/C++ programming languages

  –

  Cons

  *

  Limited to microcontroller-specific use cases

  *

  Less extensive tooling and community support compared to mainstream compilers

  *

  Limited support for advanced Wasm features

• Binaryen
  Binaryen is a compiler infrastructure project that provides a suite of tools and libraries for working with Wasm [25]. It includes a Wasm optimizer, a binary format parser, and various other utilities.

  –

  Pros

  *

  Offers powerful optimization capabilities for Wasm modules

  *

  Provides a flexible and modular toolset for working with Wasm binaries

  *

  Supports multiple input languages, including C/C++ and Rust

  –

  Cons

  *

  Primarily a development library and toolset, not a standalone compiler

  *

  Requires integration into custom build systems or toolchains

  *

  Advanced features may require more expertise to utilize effectively

• rustc (Rust)
  Rustc is the official compiler for the Rust programming language [26]. It can compile Rust code to various target platforms, including Wasm.

  –

  Pros

  *

  Offers a modern and expressive programming language with strong memory safety guarantees

  *

  Provides efficient code generation and optimization for Wasm

  *

  Offers seamless interoperability with JavaScript and other Wasm modules

  *

  Benefits from the Rust ecosystem and active community support

  –

  Cons

  *

  Requires familiarity with the Rust programming language

  *

  Compilation times can be slower compared to other compilers, and it may have a learning curve for developers new to Rust.

• Zigwasm
  Zigwasm is a compiler that enables developers to write code in the Zig programming language and compile it to Wasm [27].

  –

  Pros

  *

  Offers a modern, expressive, and safe programming language with a focus on performance

  *

  Provides seamless interoperability with C and other Wasm modules

  *

  Generates efficient Wasm code with low overhead

  –

  Cons

  *

  Smaller community and ecosystem compared to mainstream programming languages

  *

  Limited tooling and library support compared to more established languages

  *

  May require familiarity with the Zig programming language

• fable-compiler
  Fable-compiler is a compiler specifically designed for the F# programming language, targeting JavaScript and Wasm as output formats [28].

  –

  Pros

  *

  Allows developers to write code in F# and compile it to Wasm

  *

  Offers seamless integration with JavaScript and popular web frameworks

  *

  Provides interoperability with JavaScript libraries

  –

  Cons

  *

  Limited to F# programming language use cases

  *

  Smaller community and ecosystem compared to mainstream languages

  *

  Less mature compared to other compilers

• Pyodide
  Pyodide is a project that aims to bring the Python programming language to the web by compiling it to Wasm. It provides a way to run Python code directly in the browser [29].

  –

  Pros

  *

  Enables running Python code in the browser without the need for a Python interpreter

  *

  Provides access to a wide range of Python libraries and packages

  *

  Allows for interactive Python programming on the web

  –

  Cons

  *

  Limited to Python-specific use cases

  *

  Python runtime in the browser may have performance limitations compared to native Python execution

  *

  Smaller ecosystem and community compared to mainstream Python

4.2. WebAssembly Runtimes

• Wasmer
  Wasmer is a standalone runtime for executing Wasm modules. It supports multiple programming languages and provides a secure and efficient runtime environment [30].

  –

  Pros: Fast startup time, low memory footprint, supports multiple languages, supports ahead-of-time (AOT) and just-in-time (JIT) compilation, extensible with plugins.

  –

  Cons: Limited ecosystem compared to Node.js, relatively new compared to other runtimes.

• WAMR
  WebAssembly Micro Runtime (WAMR) is a lightweight and efficient runtime designed for resource-constrained devices [31]. It focuses on low memory usage and fast startup time.

  –

  Pros: Lightweight and efficient, designed for resource-constrained devices, supports AOT and interpreter execution modes, platform-specific optimizations available.

  –

  Cons: Limited language support compared to other runtimes, limited ecosystem and community support.

• Node.js
  Node.js is a popular JavaScript runtime that supports Wasm. It provides a rich ecosystem and extensive libraries and tools [32].

  –

  Pros: Vast ecosystem and community support, mature and stable runtime, easy integration with JavaScript code, wide range of libraries and tools available.

  –

  Cons: Relatively slower startup time and higher memory usage compared to some other runtimes, single-threaded by default.

• Wasmtime
  Wasmtime is a standalone runtime developed by the Bytecode Alliance. It focuses on security, compatibility, and performance [33].

  –

  Pros: High performance, supports AOT and JIT compilation, integration with the Cranelift code generator, compatible with multiple platforms.

  –

  Cons: Limited language support compared to Node.js, less mature compared to some other runtimes.

• WAVM
  Wasm Virtual Machine (WAVM) is a standalone Wasm runtime designed for high-performance applications. It focuses on providing low-latency execution [34].

  –

  Pros: High performance, low-latency execution, supports AOT and JIT compilation, compatible with multiple platforms.

  –

  Cons: Limited language support compared to Node.js, less mature compared to some other runtimes.

• Deno
  Deno is a secure JavaScript and TypeScript runtime built on the V8 engine. It provides first-class support for Wasm [35].

  –

  Pros: Secure by default, built-in module system, supports TypeScript natively, allows fine-grained control over permissions.

  –

  Cons: Relatively new and less mature compared to Node.js, limited ecosystem and library support.

• Lucet
  Lucet is a native Wasm compiler and runtime developed by Fastly. It is designed for high-performance serverless applications [36].

  –

  Pros: High-performance execution, optimized for serverless use cases, low startup time, efficient memory management.

  –

  Cons: Limited language support compared to Node.js, specialized for serverless environments.

• wascc
  Wasm Secure Capabilities Connector (wascc) is a lightweight Wasm runtime focused on secure and isolated execution of capabilities-based components [37].

  –

  Pros: Secure and isolated execution, supports capabilities-based security model, lightweight and efficient, extensible with plug-ins.

  –

  Cons: Limited language support compared to Node.js, specialized for capabilities-based component execution.

• Kotlin/JS
  Kotlin/JS is a language and runtime combination that allows writing Kotlin code that can be compiled to JavaScript or Wasm [38].

  –

  Pros: Seamless integration with Kotlin language and tooling, support for multiplatform development, interoperability with JavaScript and Wasm.

  –

  Cons: Limited language support compared to Node.js, less mature Wasm support compared to other runtimes.

• WasmEdge
  WasmEdge is a compact, efficient, and flexible runtime environment for Wasm that is designed to support a range of applications, including cloud-native, edge computing, and decentralized systems [39]. It provides the necessary infrastructure to run serverless applications, embedded functions, microservices, smart contracts, and IoT devices. WasmEdge offers high performance and can be easily extended to meet the specific needs of different use cases.

  –

  Pros: WasmEdge provides a secure execution environment, ensuring isolation and protection for system resources and memory space. It is recognized for its lightweight design and high-performance capabilities, making it suitable for serverless computing and resource-constrained environments.

  –

  Cons: WasmEdge is currently not thread-safe, which may restrict its usability in certain multi-threaded applications. While gaining popularity, its community support may not be as extensive as other well-established runtime environments, potentially impacting the availability of resources and community-driven libraries.

4.3. Build Tools/Frameworks with WebAssembly Support

• CheerpX
  CheerpX is a Wasm compiler that allows developers to compile C/C++ code into Wasm modules. It provides high-performance execution of C/C++ code in web applications, enabling developers to leverage existing codebases. CheerpX offers build optimizations to minimize code size and improve runtime performance [40]. However, it has a limited ecosystem and community support compared to other tools, and the learning curve can be moderate, especially for developers who are not familiar with C/C++.

  –

  Pros

  *

  Provides high performance by compiling C/C++ code to Wasm

  *

  Offers build optimizations to minimize code size and improve runtime performance

  *

  Suitable for leveraging existing C/C++ codebases in web applications

  –

  Cons

  *

  Limited ecosystem and community support compared to other tools/frameworks

  *

  Moderately steep learning curve, especially for developers not familiar with C/C++

• Go
  Go is a programming language that provides native support for Wasm [41]. With Go, developers can write web applications and compile them into Wasm modules. It offers high-performance execution, a rich ecosystem, and easy integration with existing Go projects. The learning curve for Go is relatively low, making it accessible to developers. However, the IoT-specific libraries and frameworks for Go may be limited compared to other languages, requiring additional effort for integrating with IoT-specific hardware.

  –

  Pros

  *

  Provides high-performance execution of Go code using Wasm

  *

  Offers a rich ecosystem with various libraries and frameworks for Go development

  *

  Easy integration with existing Go projects

  –

  Cons

  *

  Limited IoT-specific libraries and frameworks compared to other languages

  *

  May require additional effort for integrating Go with IoT-specific hardware

• Webpack
  Webpack is a popular build tool for JavaScript applications, including those targeting Wasm [42]. It offers extensive configuration options and advanced build optimization features such as code splitting and bundling. Webpack has a wide ecosystem and community support, making it a widely adopted choice. However, the learning curve for Webpack can be high due to its configuration complexity. Additionally, while it is a versatile build tool, out-of-the-box support for IoT-specific development may be limited.

  –

  Pros

  *

  Widely adopted build tool with extensive community support

  *

  Offers advanced build optimization features like code splitting and bundling

  *

  Provides a wide range of plugins and loaders for customizing the build process

  –

  Cons

  *

  Higher learning curve due to its extensive configuration options

  *

  Limited support for IoT-specific development out of the box

• Rollup
  Rollup is a JavaScript module bundler that provides efficient code bundling and tree-shaking capabilities. It is optimized for creating smaller bundles and better performance [43]. Rollup is well-suited for building libraries or smaller web applications where size and performance optimizations are crucial. However, more complex projects may require additional configuration. Similar to Webpack, Rollup has limited out-of-the-box IoT-specific support.

  –

  Pros

  *

  Optimized for creating smaller bundles and better performance

  *

  Offers tree-shaking capabilities to remove unused code

  *

  Well-suited for building libraries or smaller web applications

  –

  Cons

  *

  Requires additional configuration for more complex projects

  *

  Limited out-of-the-box IoT support

• Blazor
  Blazor is a web framework developed by Microsoft that enables developers to build interactive web applications using C# and .NET. It allows code sharing between server-side and client-side, providing a familiar development experience for .NET developers [44]. Blazor leverages Wasm to execute .NET code in the browser. While it offers the benefits of using the C# and .NET ecosystem, the performance of Blazor applications may be moderate compared to native JavaScript-based web applications. Additionally, IoT-specific libraries and frameworks for Blazor may be limited compared to JavaScript.

  –

  Pros

  *

  Allows developers to build web applications using C# and .NET ecosystem

  *

  Enables code sharing between server-side and client-side

  *

  Offers familiar development experience for .NET developers

  –

  Cons

  *

  Moderate performance compared to native JavaScript-based web applications

  *

  Limited IoT-specific libraries and frameworks compared to JavaScript

• wasm-bindgen
  Wasm-bindgen is a Rust library that facilitates seamless integration between Rust and JavaScript/Wasm. It enables efficient communication between Rust and JavaScript code, allowing developers to leverage Rust’s performance and safety features in web applications [45]. Wasm-bindgen simplifies the interaction between Rust and JavaScript by automatically generating JavaScript bindings for Rust functions and data structures. However, using wasm-bindgen requires knowledge of both Rust and JavaScript, and while it offers high performance, out-of-the-box support for IoT-specific development may be limited.

  –

  Pros

  *

  Provides seamless integration between Rust and JavaScript/Wasm

  *

  Offers efficient communication between Rust and JavaScript code

  *

  Allows leveraging Rust’s performance and safety features in web applications

  –

  Cons

  *

  Requires knowledge of both Rust and JavaScript for effective use

  *

  Limited out-of-the-box IoT-specific support

4.4. WABT: The WebAssembly Binary Toolkit

4.5. WASM Versus WASI Versus WAGI

• Wasm

  –

  Purpose: Wasm is designed to deliver high-performance code execution in web browsers and other environments. It aims to bridge the gap between high-level programming languages and the performance available with lower-level languages, allowing developers to run computationally intensive tasks on the web.

  –

  Use Cases: Wasm finds applications in various areas, including web applications that require near-native performance, porting existing applications to the web, gaming, multimedia, virtual reality, and augmented reality.

  –

  Advantages:

  *

  Performance: Wasm offers excellent performance due to its compact binary format, which allows for efficient parsing and execution.

  *

  Language-Agnostic: Wasm supports multiple programming languages, enabling developers to write code in their preferred language and compile it to Wasm.

  *

  Portability: Wasm is designed to be platform-independent, enabling code to run consistently across different systems and devices.

  *

  Web Ecosystem Integration: Wasm integrates seamlessly with the web platform, allowing access to web APIs and facilitating interactions with JavaScript.

  –

  Limitations:

  *

  Limited System Access: Wasm operates within a sandboxed environment, providing security by restricting direct access to system resources.

  *

  Lack of Standardized System Interface: Wasm does not define a standard system interface, which limits its direct interaction with the underlying operating system.

• WASI

  –

  Purpose: WASI extends the capabilities of Wasm by providing a standardized system interface [47,48]. It enables Wasm modules to interact with the host operating system in a secure and platform-agnostic manner.

  –

  Use Cases: WASI is particularly useful for system-level programming within the Wasm environment, where access to system resources such as file I/O, network communication, and system libraries is required.

  –

  Advantages:

  *

  Standardized System Interface: WASI defines a set of system calls and APIs that facilitate interactions with the host operating system in a consistent and portable manner.

  *

  Sandboxed Environment: WASI ensures secure and isolated execution of Wasm modules by enforcing restrictions on system-level interactions.

  *

  Portability: WASI enables Wasm modules to run on different platforms without modification, as it abstracts the underlying host operating system.

  *

  Compatibility: WASI allows developers to write code that can be executed on various WASI-compliant runtimes and environments.

  –

  Limitations:

  *

  Restricted System Access: Although WASI provides a standardized system interface, it imposes certain restrictions to maintain security and prevent unauthorized access to system resources.

  *

  Limited to Wasm Execution Environment: WASI is primarily focused on providing system-level interactions within the Wasm execution environment and does not extend to other technologies or platforms.

• WAGI

  –

  Purpose: WAGI is a specification that defines a standard interface for running Wasm modules as HTTP serverless functions [49,50]. It simplifies the deployment and scaling of serverless applications by leveraging the versatility of Wasm modules.

  –

  Use Cases: WAGI is particularly useful for building lightweight serverless applications, microservices, and APIs using Wasm modules.

  –

  Advantages:

  *

  Serverless Architecture: WAGI leverages the serverless paradigm, allowing developers to focus on writing business logic in Wasm modules while abstracting away server management and scalability concerns.

  *

  Language-Agnostic: WAGI supports serverless functions written in different programming languages that can be compiled to Wasm, providing flexibility for developers.

  *

  Scalability and Portability: WAGI simplifies the deployment and scaling of serverless applications by providing a standardized interface that can be used across multiple cloud providers and platforms.

  *

  Efficient Execution: Wasm’s compact binary format and optimized execution enable fast and efficient execution of serverless functions.

  –

  Limitations:

  *

  Limited System Access: Similar to Wasm and WASI, WAGI operates within a sandboxed environment, preventing direct access to system-level resources.

  *

  Focused on HTTP Serverless Functions: WAGI is primarily designed for building HTTP-based serverless functions, and may not be suitable for all types of applications or use cases.

4.6. WebAssembly Standardized Features for Existing Web Browsers and Tools

• JS BigInt to Wasm i64 Integration
  The initiation for Wasm BigInt<->i64 conversion in the JS API has been incorporated into the main specification. As a result, BigInts now have the ability to convert back and forth between 64-bit integer Wasm values. This conversion can be applied to parameters and return values of exported Wasm functions, as well as parameters and return values of host functions. Additionally, BigInts can be used with imported and exported globals. Reading from or writing to Wasm memory using BigInt64Array or BigUint64Array, as introduced in the BigInt proposal, can be done without requiring any additional support.
• Bulk Memory Operations
  The introduction of Bulk Memory Operations and Conditional Segment Initialization in Wasm addresses specific needs and optimizations related to memory operations and segment initialization.
  Bulk Memory Operations (BMO) were introduced in response to observations that functions such as memcpy and memset are frequently used and can significantly impact performance in Wasm benchmarks. This proposal aims to provide more efficient memory copying and filling operations. A prototype implementation of the memory.copy instruction was created, comparing it to an existing implementation generated by emscripten. The benchmark tests the performance of copying size bytes of data from one address to another without overlapping, and repeats this process N times. The results show potential for significant performance improvements with optimized bulk memory operations.
  Conditional Segment Initialization (CSI) is motivated by the need to share Wasm modules among multiple agents. Under the current threading proposal, if a module is shared, it needs to be instantiated multiple times, potentially resulting in multiple initializations of linear memory and overwriting of stores. CSI introduces the concept of passive segments that are not automatically copied into memory or tables during instantiation. Instead, they require manual application using the new memory.init and table.init instructions. By distinguishing between active and passive segments, finer control over memory initialization is achieved, ensuring proper sharing of modules without data corruption.
  The design of BMO involves new instructions such as memory.copy, table.copy, and memory.fill. These instructions enable efficient copying and filling of memory regions and tables. The binary format for the data section includes segments with a memory index, an initializer expression for offset, and raw data. The proposal repurposes the memory index field to serve as a flags field, allowing for additional meanings attached to nonzero values. Passive segments, indicated by the low bit of the flags field, are not automatically copied on instantiation, and require manual application using memory.init and table.init instructions. Segments can be shrunk to size zero using the data.drop and elem.drop instructions. As with passive segments, active segments have an implicit initialization and drop process as part of the module’s start function.
  Furthermore, the reference-types proposal introduces the notion of function references, and allows element segments to be used for forward-declaring functions with addresses that will be taken. The proposal introduces the bulk instructions table.fill and table.grow, which take a function reference as an initializer argument.
  The validation process and initialization behavior are updated with the bulk memory scheme. Active segments are initialized in module-definition order, with out-of-bounds checks to prevent instantiation failures. Data that have already been written for previous in-bounds segments remain unchanged.
  Instructions such as memory.init, data.drop, memory.copy, memory.fill, table.init, elem.drop, and table.copy enable efficient segment initialization, copying, and filling operations in Wasm. The parameters and signatures of these instructions determine the source and destination addresses, offsets, and sizes, ensuring that bounds checks are performed to prevent memory access violations.
  The introduction of the DataCount section addresses the issue of memory.init and data.drop instructions breaking the guarantee of single-pass validation. This new section provides information about the number of data segments defined in the Data section, enabling proper validation during the parsing of the Code section.
  Overall, these proposals enhance the memory management capabilities of Wasm, allowing for more efficient memory operations, controlled initialization of segments, and optimized sharing of modules among multiple agents.
• Extended Constant Expressions
  This approach aims to expand the capabilities of constant expressions in Wasm. The current specification for constant expressions is limited, and was always intended to be extended. This proposal introduces new instructions that can be used in constant expressions, enhancing the flexibility and functionality of this feature.
  The main motivation behind this approach comes from LLVM, where the use of integer addition in global initializers and segment initializers could provide significant benefits. These use cases are particularly relevant for dynamic linking, which is currently an experimental feature.
  In dynamic linking scenarios, data segments are relative to a global import named “__memory_base,” which is supplied by the dynamic linker. However, the current limitations prevent the expression “__memory_base + CONST_OFFSET” from being used in segment initializers. As a result, all memory segments need to be combined into one. Additionally, the linker has to generate dynamic relocations for certain Wasm globals due to the inability to initialize a global with the value of “__memory_base + CONST_OFFSET”. This situation arises when the static linker determines that a symbol is local to the module, resulting in the creation of a new global that points to a data segment, i.e., its value is an offset from “__memory_base” or “__table_base,” which are themselves imported.
  This concept introduces several new instructions that are considered valid constant instructions. These instructions include integer addition, subtraction, and multiplication for both 32-bit and 64-bit integers. The new instructions provide more flexibility and enable complex constant expressions to be used in Wasm programs.
  The concept has made progress in terms of implementation across various platforms and tools. The spec interpreter, Firefox, Chrome/v8, wabt, LLVM, binaryen, and emscripten have all implemented support for the extended constant instructions. However, the implementation status in Safari is currently unknown.
  This technqiue expands the capabilities of constant expressions in Wasm, addressing the limitations of the current specification. By introducing new instructions and enabling more complex expressions, developers can leverage enhanced functionality in their Wasm programs.
• Multi-Value
  The Multi-Value Extension approach aims to enhance the functionality of Wasm by allowing functions, instructions, and blocks to consume multiple operands and produce multiple results. While the current specification limits functions and instructions to at most one result, this proposal seeks to generalize them to accept and produce multiple values. The concept of multi-value semantics is well-understood and has been implemented in platforms such as V8.
  The motivation behind this concept is to address the asymmetries in the current Wasm design, which restrict functions and instructions to a single result. By enabling multiple return values for functions and instructions, several benefits can be achieved. This includes the ability to unbox tuples or structs returned by value, efficient compilation of multiple return values, and support for instructions that produce several results, such as divmod or arithmetic operations with carry.
  Additionally, allowing inputs to blocks opens up new possibilities. Loop labels can have arguments, enabling the representation of phis on backward edges and facilitating the future implementation of a pick operator that can cross block boundaries. The macro-definability of instructions with inputs is enabled, allowing for concise and expressive code patterns.
  This technique provides examples to illustrate the usage of multiple return values, instructions with multiple results, and blocks with inputs. These examples showcase how the extension enhances the flexibility and expressiveness of Wasm programs. For instance, a swap function can be defined to exchange two values, an addition function can produce an additional carry bit, and instructions such as divrem and add_carry can produce multiple results.
  This changes to the Wasm specification in this approach mainly involve the generalization of type syntax. The resulttype is extended from [valtype?] to [valtype*], allowing for multiple values. Block types in block, loop, and if instructions are generalized from resulttype to functype. Validation rules are adjusted accordingly, removing arity restrictions and replacing “?” with “*” in type occurrences.
  The execution of multiple results involves replacing “?” with “*” and handling the entry of blocks with operands by popping the values from the stack and pushing them back after the label.
  The binary format requires an extension to support function types as block types, allowing references to function types. The text format undergoes minimal changes, primarily in the syntax for block types, which is generalized to accommodate multiple values.
  The scheme addresses the typing of administrative instructions and provides a formulation of formal reduction rules. Possible alternatives and extensions are under discussion, including more flexible block and function types using references to the type section or unifying the encoding of block types with function types.
  An open question is whether locals are sufficient for destructuring or reshuffling multiple values, or if additional instructions such as pick or let should be introduced to enhance these capabilities.
  In summary, the Multi-Value Extension expands the capabilities of Wasm by enabling functions, instructions, and blocks to consume and produce multiple operands and results. This extension enhances expressiveness, facilitates efficient compilation, and opens up new possibilities for code patterns and optimizations.
• Mutable Globals
  Import/Export Mutable Globals aims to address the inconvenience of providing mutable thread-local values in Wasm that can be dynamically linked. The proposal focuses on the ability to import and export mutable globals, specifically using the C++ stack pointer (SP) as a motivating example. While the examples revolve around the SP, the rationale can be extended to other thread-local variables or the TLS pointer itself. The motivation behind this concept stems from the limitation of not being able to import or export mutable globals in the MVP of Wasm. To illustrate the need for mutable globals, consider the scenario of dynamically linking two modules, m1 and m2, both utilizing the C++ stack pointer. In the MVP, this cannot be achieved directly. In a single-agent program, a workaround involves storing the stack pointer in linear memory. However, this solution fails when linear memory is shared, as each agent requires a different memory location for its stack pointer. The scheme presents several solutions to address the challenge of importing and exporting mutable globals.

  –

  Solution 1

  Use Per-Module Immutable Global: one approach is to utilize a per-module immutable global to store the location of the SP in linear memory. This can be extended to other thread-local variables as well. However, this solution has drawbacks, such as the need to read the global every time the SP is accessed and the SP in linear memory being vulnerable to to interference from other agents.

  –

  Solution 2

  Use Internal Mutable Global with Shadow in Linear Memory: a mutable global can be employed to optimize SP access. In this approach, the SP is stored in a mutable global, and when crossing module boundaries it is spilled to linear memory in the caller and loaded in the callee. Although this solution could be further optimized, such as spilling SP only when necessary, it incurs additional overhead for every function call and requires spilling and loading of other thread-local values in the same manner. Moreover, the SP remains susceptible to interference from other agents.

  –

  Solution 3

  Modify Function Signature to Pass SP as Parameter: instead of spilling the SP to linear memory, it can be passed as a parameter in function signatures. However, because it is not known whether an imported function will use the SP, all exported functions must be modified accordingly. The SP value is ultimately saved in a mutable global and loaded from the parameter at function entry points. This approach provides an optimization, as passing the SP to all functions is unnecessary and it is only required for exported functions.

  –

  New Solution for Globals using Wasm.Global:

  the new solution suggests loosening the restriction on importing and exporting mutable globals to provide a better solution for thread-local values. This allows for the usage of mutable globals as thread-local storage. In the web binding, exported globals are of the Wasm.Global type rather than being converted to JavaScript Numbers. A Wasm.Global object comprises a single global value that can be simultaneously referenced by multiple Instance objects. Each Global object has two internal slots.

  The Import/Export Mutable Globals scheme aims to enhance Wasm’s capabilities by allowing the import and export of mutable globals. This enables the provision of mutable thread-local values that can be dynamically linked, addressing scenarios such as utilization of the C++ stack pointer. This proposal presents multiple solutions, highlighting the benefits and drawbacks of each approach. By allowing the import and export of mutable globals, Wasm gains greater flexibility in handling thread-local variables and opens up new possibilities for dynamic linking.
• Reference types
  The Reference Types for Wasm proposal aims to introduce new types and instructions to enhance interoperation with the host environment and provide more flexibility within Wasm. The motivation behind this proposal includes easier and more efficient interoperability, manipulation of tables (paving the way for future extensions), and smoother transition paths to features such as garbage collection.
  The proposal introduces the following key additions.

  –

  New Types

  The schem adds the type “externref,” which can be used as both a value type and a table element type. Additionally, “funcref” is introduced as a value type.

  *

  Table Instructions

  Instructions are provided to get and set table slots, ensuring that basic manipulation of tables is possible within Wasm. Furthermore, missing instructions such as table size, grow, and fill are added.

  *

  Multiple Tables

  The scheme allows for the use of multiple tables, increasing flexibility and enabling more complex data structures.

  –

  Possible Future Extensions

  The technique mentions potential future extensions that could be explored.

  *

  Subtyping

  The introduction of a simple subtype relation between reference types to enable various extensions.

  *

  Equality on References

  Allows references to be compared by identity while ensuring implementation details are not observable in a non-deterministic manner.

  *

  Typed Function References

  Enhances the representation of function pointers and enables the easy passing of functions between modules.

  *

  Down Casts

  Introduces a cast instruction to enable the implementation of generics using anyref as a top type. It is worth noting that several of the future extensions mentioned here are covered by separate proposals, such as the Typed Function References proposal and the garbage collection proposal.

  The Reference Types proposal for Wasm suggests the introduction of new types, instructions, and features to improve interoperability, table manipulation, and flexibility within Wasm. These additions aim to enhance the overall capabilities of Wasm while setting the stage for potential future extensions.
• Non-Trapping float-to-int Conversions
  The Non-Trapping Float-to-Int Conversions technique aims to address the undefined behavior of float-to-int conversions in LLVM and establish a convention for saturating operations. The primary motivations behind this proposal are to improve the consistency of float-to-int conversions and provide a convention that can be shared with SIMD operations to avoid trapping.
  The motivation for this scheme stems from LLVM’s undefined result for float-to-int conversions and the desire for SIMD operations to behave more like SIMD hardware without trapping. The proposal aims to establish a convention for saturating operations that can be used by SIMD operations, ultimately avoiding trapping. It is important to note that this proposal is driven by the desire for consistent and non-trapping conversions, not performance concerns.
  The issue of non-trapping float-to-int conversions has been discussed in various contexts, including GitHub issues and CG meetings. The discussions have involved considerations of performance effects and encoding strategies. While initial performance concerns were addressed through implementation fixes, no real-world performance problems related to this issue have been reported.
  The scheme introduces eight new instructions that provide saturating versions of float-to-int conversions for both signed and unsigned integers. The semantics of these instructions are the same as the corresponding non-saturating instructions, with the following differences:

  –

  Instead of trapping on positive or negative overflow, the saturating instructions return the maximum or minimum integer value, respectively, without trapping.

  –

  Instead of trapping on NaN, the saturating instructions return 0 without trapping.

  To accommodate the new instructions, a new prefix byte is introduced, labeled “misc”, which is intended to be used for future miscellaneous operations. The encodings for the new instructions utilize this prefix, allowing for clear differentiation from other instructions. The Non-Trapping Float-to-Int Conversions proposal presents a solution to the undefined behavior of float-to-int conversions in LLVM and introduces saturating versions of the instructions. By providing consistent and non-trapping conversions, this proposal aims to enhance the reliability and predictability of float-to-int conversions in Wasm.
• Sign-extension Operations
  The Sign-Extension Operators proposal focuses on introducing new sign-extension operators as a post-MVP feature for Wasm. This proposal aims to add support for sign-extending 8-bit, 16-bit, and 32-bit values with the introduction of five new integer instructions.
  To facilitate sign-extension, five new sign-extension operators are proposed:

  –

  i32.extend8_s: sign-extend a signed 8-bit integer to a 32-bit integer.

  –

  i32.extend16_s: sign-extend a signed 16-bit integer to a 32-bit integer.

  –

  i64.extend8_s: sign-extend a signed 8-bit integer to a 64-bit integer.

  –

  i64.extend16_s: sign-extend a signed 16-bit integer to a 64-bit integer.

  –

  i64.extend32_s: sign-extend a signed 32-bit integer to a 64-bit integer.

  It was later added for consistency, as its behavior differs from i64.extend_s/i32.
  The instruction syntax and binary format are modified to accommodate the new sign-extension operators. The instruction syntax is expanded to include the new operators, while the binary format assigns specific values to each operator for encoding purposes.
  The Sign-Extension Operators proposal offers an enhancement to Wasm by introducing new instructions that enable sign-extension for various integer sizes. By incorporating these sign-extension operators, Wasm gains increased flexibility and functionality in working with signed integer values.
• Fixed-Width SIMD
  This specification presents an extension to Wasm that introduces a 128-bit packed Single Instruction Multiple Data (SIMD) feature. This extension is designed to efficiently leverage the capabilities of current instruction set architectures commonly used in hardware.
  The primary motivation behind this proposal is to enable Wasm to utilize the SIMD instructions available in hardware, thereby achieving performance levels close to native execution speed. SIMD instructions in hardware allow simultaneous computations on packed data within a single instruction, often employed to enhance multimedia application performance. This proposal defines a portable subset of operations that closely aligns with commonly used SIMD instructions found in modern hardware.
  The Wasm extension introduces a new value type called v128 that is specifically tailored for SIMD operations. The v128 type corresponds to a 128-bit representation with bits numbered from 0 to 127. It serves as a mapping to a vector register in SIMD instruction set architectures. The interpretation of the 128 bits within the vector register is determined by individual instructions. When representing a v128 value as 16 bytes, bits 0-7 are stored in the first byte, with bit 0 as the least significant bit (LSB); bits 8-15 are stored in the second byte, and so on.
  The v128 SIMD type is versatile and capable of representing various types of packed data. For example, it can represent four 32-bit floating-point values, eight 16-bit signed or unsigned integer values, and more.
  Instructions in this specification follow a naming convention: interpretation.operation. The interpretation prefix indicates how the bytes of the v128 type are interpreted by the operation. For instance, the f32x4.extract_lane and i64x2.extract_lane instructions perform the same operation of extracting the scalar value of a vector lane. However, the f32x4.extract_lane instruction returns a 32-bit floating-point value, while the i64x2.extract_lane instruction returns a 64-bit integer value.
  The v128 vector type interpretation treats the vector as a collection of bits. The vlane_widthxn interpretations (e.g., v32x4) view the vector as n lanes, each consisting of lane_width bits. The tlane_widthxn interpretations (e.g., i32x4 or f32x4) treat the vector as n lanes, with each lane having a type of tlane_width.
  Attempting to access SIMD types in Wasm module imports or exports from JavaScript results in an error.
  If an imported function in JavaScript expects or returns a v128-type argument or result, invoking that function immediately throws a TypeError.
  When instantiating a Wasm module using a moduleObject, an exception of type LinkError is thrown if a global value has the type v128 and the imported object is not a Wasm.Global.
• Tail Calls
  This scheme aims to enable tail call optimizations in Wasm, which are currently prohibited. Tail call elimination is crucial for correct and efficient implementations of languages that rely on this optimization, as well as for certain compilation and optimization techniques such as dynamic recompilation, tracing, and CPS. By introducing tail call support, Wasm can better handle control constructs such as co-routines, continuations, and finite state machines.
  Tail calls involve unwinding the current call frame before performing the call, regardless of any differences between the caller and callee functions. This proposal introduces explicit tail call instructions distinct from the regular call instructions that explicitly disallow TCE. Tail calls behave as a combination of a return instruction followed by a call instruction, unwinding the operand stack similar to a return and keeping only the necessary call arguments. While tail calls to host functions cannot guarantee tail behavior (beyond the scope of the specification), tail calls across Wasm module boundaries do guarantee tail behavior.
  Tail calls are performed using separate call instructions designed explicitly for tail calls. This proposal introduces a tail version of each existing call instruction. An alternative approach involving a single instruction prefix applicable to every call instruction was considered and rejected by the WebAssembly Community Group. Although Wasm may include additional call instructions in the future, such as call_ref, the use of instruction prefixes as modifiers is not employed elsewhere in the Wasm specification.
  Tail calls behave as a combination of return and call instructions, as they unwind the operand stack similar to a return instruction. They only retain the necessary call arguments. It is important to note that tail calls to host functions cannot guarantee tail behavior, whereas tail calls across Wasm module boundaries do ensure tail behavior.
  Tail call instructions are stack-polymorphic due to their combining call and return operations. Previously, there was a question of whether tail calls should induce different function types. Four possibilities were considered: distinguishing tail-callees by type, distinguishing tail-callers by type, both, or neither. After careful consideration, the fourth option was chosen as the simplest option conceptually. Experimental validation showed no significant performance benefit to the first option, and bifurcating the function space with the third option could lead to difficulties with function tables and dynamic indirection.
  Validating the new instructions combines the typing rules for returns and the existing call instructions, resulting in stack-polymorphic behavior. The type of a return_call instruction with function index x is derived from the type of the function referred to by x. If x has a function type [t1*] -> [t2*], then return_call x has the type [t3* t1*] -> [t4*], where t3* and t4* can be any types provided that the current function has a return type of [t2*]. The same principle applies to return_call_indirect instructions.
  The execution semantics of the new instructions involve popping the call operands, clearing and popping the topmost stack frame like a return instruction, pushing back the operands, and then delegating to the semantics of the corresponding plain call instructions.
  The reserved opcodes following the existing call instructions are used for the new instructions in the binary format; specifically, return_call is represented by 0x12 and return_call_indirect is represented by 0x13.
  Table 8 presents a comparison of existing WebAssembly standardized features in various web browsers and tools.

5.1. Selected Articles on IoT-Wasm

5.2. OS Development

5.3. IoT Programming

5.4. Debugging

5.5. Virtual Machine

5.6. Development Environment Execution

5.7. Access Control Framework

5.8. Secure Execution

5.9. Containerization

5.10. Serverless

5.11. Applications and Evaluation

5.12. Edge–Cloud Integration

6.1. Limitations of Current WebAssembly Implementations

• Lack of Garbage Collection
  One of the major hurdles when dealing with Wasm in the context of IoT is the lack of native support for garbage collection. Garbage collection is a form of automatic memory management that can greatly simplify programming, and is a critical feature in many high-level programming languages. Wasm does not directly support garbage collection, which can complicate things for developers.

  –

  Understanding the Problem

  Garbage collection is the process of identifying and freeing up memory that is no longer in use by the program. It is used in many modern programming languages, including JavaScript, Python, Java, and Go. The absence of native garbage collection support means languages that rely on it cannot be fully or effectively compiled to Wasm.

  In IoT scenarios, where devices often have constrained memory resources, efficient memory management is essential. Without garbage collection developers have to manually manage memory, which is more challenging and error-prone as well as time-consuming.

  –

  Current Solutions and Workarounds

  For languages such as C and C++, which do not use garbage collection and allow developers to manually manage memory, this is not an issue. However, for languages that depend on garbage collection there are a few solutions and workarounds.

  *

  Compile the Garbage Collector

  One approach is to compile the garbage collector of the source language into Wasm along with the program itself. This can make the resulting Wasm module self-contained and capable of doing its own garbage collection. However, this can significantly increase the size of the resulting module, which might not be suitable for IoT devices with limited memory.

  *

  Use WASI

  The WASI provides a capability-oriented system interface that allows Wasm modules to interact with system resources, including memory management.

  *

  Use Linear Memory

  Wasm’s linear memory can be manipulated manually from within Wasm code (or from JavaScript, if running in a browser environment). However, this places the burden of memory management onto the programmer, increasing complexity.

• Interoperability Challenges
  Interoperability refers to the ability of different systems or applications to communicate, exchange, and utilize data effectively. It is a critical aspect of modern technology stacks, in which multiple languages, libraries, and services often need to work together seamlessly. There are certain interoperability challenges that emerge when considering Wasm in the context of IoT, predominantly due to the varying nature of IoT devices and Wasm’s unique operational dynamics.

  –

  Communication between JavaScript and WebAssembly

  While Wasm was designed to coexist with JavaScript in a web environment, communication between the two is not always straightforward. Currently, interaction between JavaScript and Wasm is mainly restricted to numeric data types. This constraint means that transferring more complex data types such as strings or objects between JavaScript and Wasm requires them to be broken down into simple numeric components or transferred using shared memory. The process of data conversion adds an extra layer of complexity to application development, and can introduce a performance overhead. It requires careful management to ensure data integrity, and can lead to errors if not properly implemented. While proposals such as Wasm Interface Types aim to improve this, the problem remains a significant challenge for developers.

  –

  Compatibility With Various Devices

  IoT devices come in various forms and use a range of software and hardware configurations. Certain IoT devices might use different architectures and operating systems, creating a need for additional layers of abstraction in the application code. Wasm’s goal of “write once, run anywhere” promises to ease this problem by providing a universal binary format. However, the Wasm runtime needs to be ported to each new system architecture, which can require considerable effort. Even then, the device’s resource constraints, such as memory, CPU power, or battery life, can limit the complexity or the number of Wasm modules that can be used.

  –

  Interactions with IoT Protocols

  IoT applications often communicate using IoT-specific protocols such as MQTT, CoAP, and DDS. Currently, Wasm cannot directly interact with these protocols because it has no direct access to the underlying system or network I/O operations. Therefore, developers need to rely on JavaScript or the host environment to manage these interactions, which may not always be feasible or efficient in an IoT context. The existing interoperability issues pose hurdles for developers, and addressing these challenges is a critical area of focus in the ongoing evolution of Wasm. With further development and enhancements, Wasm’s impact on the IoT world could be revolutionary, turning these challenges into opportunities for creating more robust, efficient, and secure IoT applications.

• Memory Management
  The manual memory management required by Wasm’s design can pose challenges for developers used to languages with automatic memory management. This can lead to a steep learning curve and potential memory management issues. In the context of Wasm and IoT, managing memory efficiently presents a distinct set of challenges. The uniqueness of the Wasm memory model and the often resource-constrained nature of IoT devices amplify these challenges.

  –

  Wasm’s Linear Memory Model

  Wasm employs a linear memory model in which all data (both code and state) are stored in a large contiguous block of memory. This model is simple and efficient, making it easy for the Wasm virtual machine to manage memory. However, it means that the application must manually manage memory allocation and deallocation. This is a complex task and prone to human error, with potentially serious consequences such as memory leaks or buffer overflows.

  –

  Lack of Automatic Garbage Collection

  Wasm does not yet have support for automatic garbage collection, which is a feature found in many high-level languages that automatically reclaims memory no longer in use. Although there is ongoing work to add garbage collection support to Wasm, the lack of it currently means that developers must manually manage memory, increasing the complexity of developing Wasm applications. This issue is particularly important in the context of IoT, where devices are often constrained in terms of memory resources. An IoT application with inefficient memory usage can easily consume too much memory, potentially causing the device to crash or behave unpredictably.

  –

  Limited Memory Resources on IoT Devices

  IoT devices range from powerful edge servers to tiny sensors with very limited processing power and memory. For devices at the lower end of this spectrum, the relatively large size of the Wasm runtime and the memory consumed by Wasm applications can be a significant problem. Developers must carefully optimize their applications to reduce memory usage, a task that is made more difficult by the current limitations of Wasm’s memory management.

  –

  Difficulty Debugging Memory Issues

  Wasm’s binary nature and the lack of a built-in debugger make debugging memory-related issues challenging. While developers can use tools such as source maps to map the Wasm code back to the original source code, these tools might not always provide enough information to diagnose a memory problem. Additionally, the linear memory model of Wasm is very low-level, making it difficult to understand how memory is being used and where potential problems might lie.

• Limited Access to Web APIs
  Wasm modules do not have direct access to web APIs and need to go through JavaScript, which can result in performance bottlenecks and increased complexity. Wasm’s integration into the web ecosystem presents unique challenges, particularly in the context of access to web APIs. While Wasm has been designed to work alongside JavaScript, its ability to directly access web APIs has been a significant concern, especially for IoT applications.

  –

  Restricted Direct Access to Web APIs

  Wasm cannot directly access the web APIs that JavaScript can. Instead, in order to use these APIs Wasm needs to call out to JavaScript, which can be a cumbersome and inefficient process. This is due to the fact that Wasm runs in a sandboxed environment to ensure security, which inherently limits its ability to directly interact with the host environment. For IoT applications, this limitation can be particularly restrictive. Many IoT applications require real-time interaction with various system APIs for tasks such as device control, data collection, and communication with other devices or services. The current inability of Wasm to directly access these APIs adds an extra layer of complexity to building these applications.

  –

  WASI and Interface Types

  To address these limitations, two proposals are being developed in the Wasm community: the WASI and Interface Types. The WASI aims to provide a system interface for Wasm that abstracts away the details of the host system. This allows Wasm applications to interact with the system without compromising security. The WASI, however, is mainly designed for server-side or standalone applications, and does not provide access to most web-specific APIs. Interface Types, on the other hand, aim to define a way for Wasm modules to communicate with each other and with the host environment using high-level data types. This would allow Wasm to interact with web APIs in a more direct and efficient way without needing to go through JavaScript. These two proposals, if accepted and implemented, would go a long way in addressing the current limitations of Wasm in terms of API access.

  –

  Implications for IoT

  The current state of Wasm’s limited access to web APIs presents a challenge for IoT development. However, the advancements in the form of WASI and Interface Types bring a promising future. Access to web APIs in a more direct and efficient manner would enable developers to build more sophisticated, high-performing, and secure IoT applications using Wasm.

• Debugging and Testing Challenges
  In light of its binary nature, debugging and testing Wasm applications can be more challenging compared to JavaScript. While a number of tools are available, they often provide less visibility and convenience than developers are accustomed to. As Wasm finds its footing in the landscape of IoT development, the challenges associated with debugging and testing of Wasm modules are becoming increasingly evident. These challenges stem from a few aspects of Wasm’s design and the current state of tooling.

  –

  Lack of Mature Debugging Tools

  While Wasm’s design is optimized for efficient execution, its binary format makes debugging a complex task. Compared to traditional programming languages, debugging tools for Wasm are in their nascent stages. While there are debugging protocols available, such as Dwarf for Wasm, they may not be as mature or fully featured as those available for other languages.

  –

  Source Map Limitations

  Source maps are used to map the compiled Wasm code back to the original source code, making debugging easier. However, the effectiveness of source maps can be limited by the fact that they only provide information about where the code originated, not how the compiled code is behaving. This can make it harder to debug complex issues that involve the runtime environment or interactions between different parts of the code.

  –

  Interoperability Issues

  Considering the interoperability of Wasm with JavaScript and other web technologies, debugging can be complicated by issues that span multiple languages and technologies. For instance, an issue might involve both JavaScript and Wasm code, requiring developers to use different tools and strategies to debug different parts of the application.

  –

  Testing Challenges

  Similar to debugging, testing Wasm modules, especially in the context of IoT applications, presents its own set of challenges. Considering the wide variety of devices and environments in IoT, it can be difficult to effectively test Wasm applications in order to ensure they work correctly in all potential scenarios.

• Restricted Networking Capabilities
  In its current state, Wasm lacks direct access to networking APIs, limiting its capabilities for networking tasks without interaction with JavaScript, which can introduce complexity and performance drawbacks. As Wasm’s use expands in the world of IoT, it encounters unique challenges, one of which is its restricted networking capabilities. This section highlights these challenges and discusses their impact on the use of Wasm in IoT applications.

  –

  Wasm’s Networking Model

  Wasm currently operates within the constraints of the same-origin policy, meaning that it can only make network requests to the same source from which the Wasm module was loaded. While this policy is a crucial security feature in web environments, it can limit the direct networking capabilities of Wasm, particularly in the context of IoT, where devices often need to communicate with different servers and devices.

  –

  Lack of Direct Access to Networking APIs

  As of now, Wasm does not have direct access to networking APIs. This means that Wasm applications must rely on the host environment, typically a JavaScript environment in a web browser, to make network requests on their behalf. This lack of direct access can lead to inefficiencies and makes it more difficult to implement networking functionality in a straightforward manner.

  –

  Implications for IoT

  These networking restrictions can be particularly problematic for IoT applications. IoT devices often need to communicate with various servers, devices, and services, often across different origins. The lack of direct access to networking APIs presents a challenge, as it means that all networking operations must go through the host environment, which could potentially impact performance and introduce additional complexity.

  –

  Potential Solutions

  Proposed solutions to this challenge involve extending Wasm’s capabilities either through new Wasm APIs or via the WASI. In particular, the latter aims to provide Wasm applications with more direct access to system capabilities, including networking. This evolution could significantly enhance the utility and power of Wasm in the context of IoT.

6.2. Challenges in IoT Integration with WebAssembly

• IoT Device Garbage Collection
  Garbage collection is a critical feature in many programming languages, helping to manage memory automatically by detecting and freeing up memory that is no longer needed and thereby reducing the risk of memory leaks. While JavaScript has built-in garbage collection, Wasm currently lacks this feature. However, there is a promising proposal on the horizon to introduce garbage collection to Wasm, which could have significant implications for its application in IoT contexts.
  The proposal for garbage collection in Wasm aims to offer the same level of memory management that high-level languages such as JavaScript, Python, and Ruby provide, with the goal of enabling these and other languages to target Wasm more efficiently. The integration of garbage collection into Wasm could vastly simplify the development process, improve performance, and make Wasm a more attractive and feasible choice for a wider range of applications, including IoT.
  By enabling managed languages to compile to Wasm efficiently, it would become much easier to port existing libraries, tools, and applications to run in the Wasm environment without the need for complex workarounds or compromises. This could lead to a significant increase in the ecosystem of available software and libraries, which would in turn boost the utility and versatility of Wasm.
  Moreover, the addition of garbage collection could reduce the size of Wasm modules by allowing them to leverage the host environment’s garbage collector instead of having to include their own memory management code. This would make the modules more lightweight and faster to load, which is an important consideration in the bandwidth-constrained environments typical of IoT.
  However, introducing garbage collection into Wasm is a complex task, and there are several challenges that need to be addressed. For example, there needs to be a balance between the increased overhead of garbage collection and its benefits. In addition, it is important to ensure that the garbage collector is efficient and does not introduce significant performance overhead.
  Overall, the proposal of garbage collection for Wasm represents an exciting direction for the future. The successful implementation of this feature could unlock a new level of functionality and efficiency, paving the way for a broader application of Wasm in IoT and other domains. As such, it will be crucial to monitor the progress of this proposal and its potential impact on the Wasm ecosystem.
• Enhancing the WebAssembly Ecosystem
  Efforts are ongoing to further develop and refine the tooling and libraries around Wasm with the aim of addressing current challenges and making the technology more approachable and easier to use.
  A robust and well-supported ecosystem is vital for the success and wider adoption of any technology. As of now, the Wasm ecosystem is burgeoning, propelled by its promising capabilities and the support of industry stalwarts such as Google, Mozilla, Microsoft, and Apple. However, there is much to be done in order to fully realize its potential, especially in the IoT domain. Here, we discuss key future directions for enhancing the Wasm ecosystem.

  –

  Improved Tooling

  Improving the toolchain is crucial for the broader adoption of Wasm. This includes refining existing tools and developing new ones that cater specifically to the needs of Wasm developers. For example, creating user-friendly debuggers, profilers, and performance analyzers designed for Wasm can significantly ease the development process and foster its adoption.

  –

  Broadening Language Support

  While Wasm currently supports a variety of languages, broadening this support is essential. Efforts should be aimed at making the compilation to Wasm seamless and efficient for a wider array of languages. This would enable developers of different backgrounds and expertise to leverage the benefits of Wasm, promoting its use in diverse applications, including IoT.

  –

  Encouraging Community Engagement

  One of the most effective ways to enhance the Wasm ecosystem is to foster a strong and active community of developers and users. This not only fuels the evolution of the technology through a constant influx of ideas and improvements, it helps to uncover new possibilities for its application. In the context of IoT, this could mean finding innovative ways to use Wasm in edge computing, wearable technology, smart homes, and more.

  –

  Establishing Standards and Best Practices

  As Wasm matures, it is crucial to establish clear standards and best practices for its use. This includes defining guidelines for security, performance optimization, interoperability, and more. Establishing these standards can streamline the development process and ensure that Wasm applications are robust, secure, and efficient.

  –

  Developing IoT-Specific Libraries and Frameworks

  In light of the unique constraints and requirements of IoT applications, developing libraries and frameworks specifically designed for IoT could significantly accelerate the adoption of Wasm in this domain. These could provide out-of-the-box solutions for common IoT tasks such as networking, data processing, and device management, easing the development process and improving efficiency.

• Enhanced Security Features
  Security is a priority for future Wasm updates, with expectations for enhanced memory protection, more granular control over system resources, and improvements to the existing sandboxing mechanisms to further secure Wasm execution. In an era where cyberthreats are increasing in both number and sophistication, security is a paramount concern for any computing system, and the IoT landscape is no exception. In fact, the distributed nature of IoT networks and the sensitive data they often handle makes security even more critical. In this section, we discuss potential future directions for enhancing the security features of Wasm in IoT applications.

  –

  WebAssembly and Secure Execution Environments

  In the future, there could be an increased focus on integrating Wasm with secure execution environments (SEEs) such as Intel SGX, ARM TrustZone, or even custom-built SEEs. This could enable sensitive computations to be isolated at a hardware level, providing a higher degree of security than software-level isolation mechanisms alone. In this scenario, Wasm could serve as a portable and efficient execution format for code running inside these secure environments.

  –

  Formal Verification of Wasm Code

  Another direction could be the application of formal methods to verify the security properties of Wasm code. Formal methods involve mathematically proving that a piece of software satisfies certain properties, and are typically used in high-assurance systems where security is critical. By developing tools and methodologies for formally verifying Wasm code, it could be possible to provide strong mathematically-backed guarantees about the security of Wasm applications.

  –

  Fine-Grained Sandboxing

  While Wasm already operates in a sandboxed environment, future developments could see a move towards more fine-grained sandboxing mechanisms. This could involve isolating different components of a Wasm application from each other, thereby limiting the potential impact of a security vulnerability in one component.

  –

  Enhanced Cryptographic Capabilities

  Wasm could be extended with more advanced cryptographic capabilities, such as support for secure multi-party computation (SMPC), homomorphic encryption, or quantum-resistant cryptography. These enhancements could allow Wasm to securely handle sensitive data in a wider range of scenarios, and could be particularly beneficial in IoT networks, where sensitive data is often transmitted between devices.

  –

  Improved Auditability and Transparency

  With the potential integration of blockchain technology into IoT, the aspect of auditability and transparency of code execution becomes crucial. Wasm, with its human-readable text format (WAT), can play a significant role here. Enhancements can be made to the Wasm ecosystem to facilitate the verification and auditing of code.

• Improved Networking Capabilities
  Efforts are underway to provide Wasm with direct access to networking APIs in order to eliminate the need for JavaScript intermediation and unlock the potential for more powerful and efficient networked applications. Networking is a crucial aspect of any IoT application. Devices in an IoT network communicate with both each other and with cloud-based services, necessitating reliable, efficient, and secure networking capabilities. However, Wasm’s initial design does not have inherent networking capabilities, instead relying on the host environment for this. In the future, there are several directions Wasm could take to improve networking capabilities in the context of IoT.

  –

  Networking APIs in WebAssembly

  One of the most promising developments in Wasm is the proposal for adding networking APIs directly to the WASI. This would allow Wasm applications to establish network connections, send and receive data, and perform other networking operations without relying on JavaScript or other host environment features. This could significantly improve the efficiency of networking in Wasm-based IoT applications.

  –

  Peer-to-Peer Networking

  Peer-to-peer networking is an important feature for many IoT applications, especially those that involve direct device-to-device communication. Future versions of Wasm could include support for peer-to-peer networking protocols, allowing devices to establish direct connections with each other without needing a central server.

  –

  Secure Networking

  Security is paramount in IoT networking due to the sensitive nature of the data being transferred. Future developments could focus on enhancing the security of Wasm’s networking capabilities, for instance by integrating secure networking protocols directly into Wasm or providing APIs for cryptographic operations.

  –

  Network Performance Optimization

  Efficient use of network resources is important in IoT, especially in applications where bandwidth is limited or expensive. Future iterations of Wasm could include features for optimizing network performance, such as support for data compression or efficient binary protocols.

  –

  Advanced Networking Features

  There are numerous other advanced networking features that could be beneficial in an IoT context. For example, support for multicast or broadcast communication could allow a single Wasm application to efficiently send data to multiple devices. Similarly, support for real-time communication protocols could enable use cases such as VoIP or live video streaming.

6.3. Role of WebAssembly in Advancing IoT

• Performance Optimization in IoT Devices
  Wasm plays a crucial role in advancing the performance optimization of IoT devices thanks to its compact binary format, efficient execution, and ability to work seamlessly with other web technologies. Here, we delve deeper into the elements that make Wasm a key player in performance optimization for IoT.

  –

  Efficient Binary Format

  Wasm’s binary format is both compact and designed for fast parsing, two factors which greatly benefit performance. On resource-constrained IoT devices, these qualities make it possible to execute complex tasks with less memory and processing power than traditional interpreted languages. Furthermore, its compact size allows for faster download times, a critical advantage for devices operating on networks with limited bandwidth.

  –

  Near-Native Execution Speed

  Wasm code is compiled to a form that is very close to machine code, enabling it to execute at near-native speed. This speed advantage is particularly beneficial in the IoT space, where devices must often process data and make decisions in real time.

  –

  Interoperability with JavaScript and Web APIs

  Wasm is designed to interoperate seamlessly with JavaScript and existing web APIs, enabling it to take advantage of the broad ecosystem of web technologies. This interoperability can lead to performance improvements, as developers can use each technology for what it does best, such as using Wasm for compute-intensive tasks and JavaScript for interaction with web APIs.

  –

  Thread and Memory Management

  Wasm’s linear memory model and its proposal for threading capabilities play a significant role in performance optimization. For devices handling complex operations or managing multiple processes simultaneously, Wasm’s efficient memory management and potential multithreading support can boost performance significantly.

  –

  Edge Computing Applications

  Wasm’s performance characteristics make it particularly well-suited to edge computing applications, which aim to reduce latency by performing data processing at the edge of the network closer to the source of data. Wasm’s high execution speed and low resource requirements enable it to run complex algorithms on edge devices, which are often resource-constrained.

• Strengthening Security in IoT
  Wasm’s sandboxing and planned security enhancements can significantly bolster IoT security. As a result, it could serve as a powerful tool to mitigate common security risks such as buffer overflow and injection attacks. The role of Wasm in enhancing the security of IoT ecosystems is of immense value. Due to their pervasive nature and the sensitivity of the data they often handle, IoT devices are attractive targets for attackers. Wasm, with its security-focused design, offers several key elements that can help to strengthen the security of IoT deployments.

  –

  Strong Isolation

  Each Wasm module operates within a well-defined sandbox environment. This means that code executing in one Wasm module is isolated from both the host system and other Wasm modules, preventing any malicious activity from affecting other parts of the system. This isolation makes it difficult for attackers to exploit vulnerabilities in one part of the system to compromise others.

  –

  Managed Memory

  Wasm’s memory model offers security advantages as well. Wasm programs manipulate a linear memory array, which is isolated from the host memory and checked for out-of-bounds accesses. This model helps to prevent common vulnerabilities such as buffer overflows that attackers could otherwise exploit.

  –

  Secure Interactions

  Interactions between Wasm and the host environment (typically JavaScript in a browser context) are strictly controlled, with a clear interface for calling functions and transferring data. This clear interface makes it harder for an attacker to trick the program into executing malicious code or accessing sensitive data.

  –

  Futuristic Scope

  Proposed enhancements to Wasm, such as the addition of garbage collection and the WASI, could offer additional security benefits. Garbage collection can help prevent memory leaks, which can sometimes be exploited to carry out attacks, while WASI could provide a more secure way for Wasm modules to interact with system resources.

• Enabling Advanced Features in IoT
  Wasm’s efficient execution can enable more advanced features in IoT devices, including edge computing, real-time analytics, and machine learning. As Wasm continues to evolve and improve, it can be expected that these capabilities will be further enhanced. Wasm’s potential extends beyond the immediate benefits of performance and security. Its flexibility and portability open doors to new possibilities for the advancement of IoT applications. This section explores how Wasm can enable more advanced features in the IoT realm.

  –

  Edge AI and Machine Learning

  The high performance of Wasm enables the deployment of Artificial Intelligence (AI) and Machine Learning (ML) models directly onto edge devices. This capability allows IoT devices to make intelligent decisions in real time without relying on a cloud-based service, thereby reducing latency and bandwidth usage. Additionally, running AI/ML models on-device can offer privacy benefits, as sensitive data no longer need to be transmitted over the network.

  –

  Digital Twins

  Wasm’s cross-platform compatibility can play a significant role in the implementation of digital twins, a concept that involves creating a digital replica of a physical object or system. Wasm allows the same digital twin code to run on various platforms, from small IoT devices to cloud servers, enabling real-time synchronization between the physical entity and its digital replica.

  –

  Advanced Augmented Reality (AR)

  Wasm can power more advanced AR applications in wearable IoT devices such as smart glasses. Its efficiency and performance can enable complex AR tasks such as object recognition or positional tracking to be performed directly on the device, offering a more responsive and immersive user experience.

  –

  Ubiquitous Computing

  Wasm’s portability and efficient performance make it a promising technology for ubiquitous computing, a concept in which computing is embedded in everyday objects and activities. With Wasm, developers can write code once and run it on a multitude of devices, facilitating the integration of computing into peoples’ daily lives.

• Standardization of IoT Development
  The language-neutral and platform-agnostic nature of Wasm could contribute to standardization in IoT development, reducing fragmentation and simplifying the development process across various platforms and devices. The IoT landscape is inherently diverse and fragmented, with a multitude of different devices, platforms, and technologies. This fragmentation can often be a barrier to the widespread adoption and development of IoT applications. Here, Wasm’s platform-agnostic nature and standardization can provide a unifying layer to facilitate the standardization of IoT development.

  –

  Unifying the Development Process

  Wasm offers a single uniform target for all IoT developers. Its universal bytecode can be executed on any device that has a Wasm runtime, regardless of the underlying hardware or operating system. This universality simplifies the development process, as developers no longer need to build different versions of the same application for different platforms; instead, they can focus on building one version that can run across all platforms.

  –

  Facilitating Code Reuse

  The ability to write code once and run it anywhere encourages code reuse. In traditional IoT development, code often needs to be rewritten when moving from one platform to another due to differences in APIs, operating systems, or hardware capabilities. Wasm mitigates this issue, as the same Wasm code can be used across different devices and platforms.

  –

  Ensuring Predictable Performance

  Wasm’s low-level nature ensures that it offers predictable performance across platforms. Its compact binary format is designed for fast download, parsing, and execution. This predictability allows developers to create applications with consistent performance regardless of the platform on which they are running.

  –

  Promoting Interoperability

  Wasm promotes interoperability among IoT devices. It can serve as a universal runtime for executing IoT applications, allowing devices from different manufacturers and platforms to run the same application code and communicate more seamlessly with each other.

• Resource Management in IoT
  Wasm’s efficient memory and resource utilization could play a critical role in managing the constrained resources of IoT devices, thereby enhancing their performance and capabilities. In IoT systems, resource management is a critical consideration. IoT devices, ranging from small sensors to more complex machines, usually operate under tight resource constraints, including limited processing power, memory, storage, and energy. Wasm, with its compact, low-level format and efficient execution model, offers several advantages for resource management in IoT.

  –

  Efficient Use of Processing Power

  Wasm’s compact binary format and efficient execution model ensure that it uses processing power optimally. Unlike interpreted languages, which require parsing and interpreting at runtime, Wasm’s bytecode is pre-compiled and can be executed quickly by the Wasm virtual machine. This reduces the processing overhead, making it ideal for resource-constrained IoT devices.

  –

  Compact Memory Footprint

  Wasm has a compact memory footprint. It uses a linear memory model, which provides a single, contiguous array of bytes representing the application’s memory. In combination with Wasm’s efficient use of memory, this model reduces the amount of memory needed to run applications, an important advantage for memory-limited IoT devices.

  –

  Energy Efficiency

  Efficient use of processing power and memory translates to energy efficiency, a critical consideration for IoT devices, many of which are battery-powered. By minimizing the computational resources needed to run applications, Wasm helps to reduce the energy consumption of IoT devices, extending their battery life and reducing the overall energy footprint of the IoT system.

  –

  Granular Control over Resources

  Wasm’s low-level nature provides developers with granular control over system resources. For example, developers can control memory allocation and deallocation explicitly in Wasm, which is often not possible in high-level languages. This control allows for more efficient use of resources and can lead to better performance and reduced resource consumption.

  –

  Future Developments

  Proposed enhancements to Wasm, such as the introduction of garbage collection and improved resource management primitives, are expected to further enhance Wasm’s resource management capabilities for IoT. These developments can help to address the current limitations and make Wasm an even more attractive option for resource-constrained IoT devices.

7.1. Prospective WebAssembly Specifications

• WASI
  The WASI is another promising future specification. It seeks to standardize the way in which Wasm modules interact with the underlying operating system to facilitate consistent and secure system calls. With WASI, developers can create universal applications that are platform-independent, enhancing the portability of Wasm. For IoT, this could mean that a single Wasm module could run on a myriad of devices, irrespective of the device’s specific operating system or architecture.
• Multi-Threading and SIMD Support
  Future specifications of Wasm include the introduction of multi-threading and SIMD support. Multi-threading would allow Wasm applications to execute multiple threads simultaneously, significantly increasing computational speed and efficiency for multi-core processors. SIMD, on the other hand, would enable a single operation to be performed on multiple data points at once, which is crucial for heavy computational tasks such as graphics rendering, audio processing, or machine learning algorithms.
• Enhanced Debugging Support
  Another area of focus for future Wasm specifications is enhanced debugging support. At present, debugging Wasm code can be challenging, especially when compared to more traditional languages such as JavaScript. Future enhancements promise a more accessible and efficient debugging process, enabling developers to easily track and fix bugs within their Wasm code. This would make the development process more streamlined while resulting in more stable and reliable Wasm applications.
• Module Types The Module Types proposal is a future specification that aims to provide a robust mechanism for defining the interface of a Wasm module. This includes the functions it exports, the types of these functions, the memories it uses, and more. With this feature, developers could build more complex modular applications with clearly defined interactions between different modules.

7.2. Need for Garbage Collection and Resource Management

• The Impact of Garbage Collection
  Garbage collection has a profound impact on software development. The automatic memory management provided by garbage collection removes the burden of manually tracking and freeing up unused memory from developers, prevents memory leaks, and reduces the likelihood of certain types of bugs.
  In the context of Wasm, the addition of garbage collection support could drastically simplify the process of compiling high-level garbage-collected languages to Wasm. Languages such as JavaScript, Python, and many others use garbage collection, and their direct compilation to Wasm would be more straightforward with the introduction of garbage collection support.
• Resource Management Advancements
  In addition to garbage collection, future improvements to Wasm’s resource management capabilities are expected to evolve. Currently, Wasm operates with a linear memory model, which offers simplicity and performance advantages but presents limitations. As IoT devices continue to grow in complexity and capability, more sophisticated memory management techniques may be needed.
  Future developments could see the emergence of more advanced memory models in Wasm, including support for shared memory between modules or even between threads. This would allow for more complex multi-threaded applications and for modules that can communicate and share data more efficiently.
• Garbage Collection and IoT
  In the specific context of IoT, the addition of garbage collection to Wasm could provide significant advantages. IoT devices often need to run for extended periods without manual intervention, and can ill afford memory leaks or other resource management issues that can disrupt their operation. Thus, the inclusion of automatic garbage collection would enhance the reliability and robustness of Wasm-based IoT applications.

7.3. Exception Handling

7.4. Memory64

7.5. Multiple Memories

7.6. Threads and Atomics

7.7. Type Reflection

7.8. Need for Enhanced Security Measures

• Expanding Sandbox Capabilities
  One of the key security features of Wasm is its sandboxing mechanism, which isolates Wasm modules from each other and from the rest of the system. This containment prevents a module from affecting other parts of the system in case it becomes compromised. Future developments could further enhance this sandboxing mechanism to provide even stronger isolation and control over module interactions, as well as to provide more granular permissions and capabilities to each module.
• Advanced Cryptographic Features
  Cryptography is a cornerstone of secure communications, and as Wasm is increasingly used for IoT applications we may see the introduction of advanced cryptographic features directly into the Wasm standard. This could include possibilities such as built-in support for encryption and decryption functions, digital signatures, secure random number generation, and other cryptographic primitives. These features would make it easier for developers to build secure IoT applications with Wasm while potentially improving performance by providing these capabilities at a low level.
• Hardware Security Integration
  Another promising direction for enhancing Wasm’s security is deeper integration with hardware security features. Many modern processors offer hardware-level security features such as secure enclaves, which provide a protected area of memory where sensitive data can be processed securely. Through integration with these features, Wasm could offer an even higher level of security for IoT applications.
• Fine-Grained Access Control
  As Wasm evolves, we may see the introduction of more fine-grained access control mechanisms. These could allow for detailed control over what resources a Wasm module can access, such as specific devices, network interfaces, or files. This would provide an additional layer of security by ensuring that a module can only access the resources it needs to function and nothing more.
• Security in a Multi-Tenant Environment
  With the rise of edge computing and the proliferation of IoT devices, there may be situations in which multiple Wasm applications coexist on the same device. In such scenarios, ensuring isolation and security in a multi-tenant environment would be crucial. Future Wasm specifications could cater to such use cases, providing robust security mechanisms to ensure data privacy and system stability.

7.9. Prospective WebAssembly Ecosystem Growth

• Expansion of Development Tools
  The future will likely see a proliferation of development tools tailored for Wasm and IoT. This could include more comprehensive debuggers, performance profilers, module optimizers, and improved IDE support for languages compiling to Wasm, with the goal of making the development process as seamless as possible from writing code to debugging and deployment.
• Growth of Libraries and Frameworks
  Libraries and frameworks play a crucial role in easing the development process by providing pre-written code for common tasks. As the Wasm ecosystem matures, the number of available libraries and frameworks can be expected to increase. These could range from low-level libraries for things such as network communication and hardware interaction to high-level frameworks that provide entire boilerplate IoT applications.
• Community Expansion
  The Wasm community’s expansion, including developers, users, and researchers, is crucial for its growth. A larger community means more collaboration, which leads to more tools, more libraries, and more shared knowledge. This could lead to increased contributions to the Wasm specification itself, thereby driving the language’s evolution.
• Increased Industry Adoption
  Increased industry adoption of Wasm is another key aspect of the ecosystem’s growth. As more businesses realize the benefits of using Wasm for their IoT solutions, there are likely to be more industry-sponsored projects, job opportunities for Wasm developers, and overall investment in the ecosystem.
• Education and Training
  As the demand for Wasm in IoT applications grows, so will the need for education and training in this area. This could result in more online courses, workshops, and resources for learning Wasm and how to use it in the context of IoT.

7.10. Prospective Alignments with Technologies

• Dew Computing
  Dew computing, an emerging concept in the realm of IoT, envisions a paradigm in which computing and data processing capabilities are distributed across the network’s edge, closer to the IoT devices and sensors themselves. In the context of futuristic use cases in IoT, Wasm can play a crucial role in enabling dew computing architectures. By leveraging Wasm, IoT devices can execute lightweight and efficient code at the edge, reducing reliance on cloud infrastructure and minimizing latency. Wasm’s ability to run on resource-constrained devices makes it an ideal technology for enabling intelligent edge analytics and decision-making. With Wasm, IoT devices can perform real-time data processing, advanced machine learning tasks, and local decision-making all while maintaining low power consumption and ensuring fast response times. This empowers IoT deployments with the ability to derive valuable insights, make autonomous decisions, and respond to critical events in a timely manner even in scenarios with limited connectivity or stringent privacy requirements. Wasm’s versatility and compatibility make it a promising technology for realizing the potential of dew computing in futuristic IoT use cases.
• WebAssembly and AI
  AI has become a fundamental component in a variety of technology sectors, bringing automation and intelligence to tasks traditionally requiring human intervention. As we anticipate the future of Wasm, its role in enhancing and accelerating AI applications is an intriguing subject. This section delves into the potential intersections between Wasm and AI.

  –

  Why Wasm for AI?

  The use of Wasm in AI can be attributed to its core strengths of performance, portability, and security. These attributes can significantly influence the development, execution, and scalability of AI applications.

  –

  Wasm and AI Models

  Many AI models, especially those involving deep learning, require substantial computational power. Currently, these models are typically trained on powerful servers and executed on the edge, for instance, in a user’s browser or on an IoT device. This execution often relies on JavaScript, which, while highly portable, does not deliver the performance of a compiled language. Wasm, with its near-native execution speed, offers a compelling alternative for executing AI models on the edge, potentially improving performance and responsiveness.

  –

  Wasm and On-Device AI

  Wasm can enhance on-device AI capabilities. In many scenarios, running AI models directly on end-user devices such as smartphones or IoT devices can provide benefits in terms of latency, privacy, and bandwidth. However, these devices often have diverse architectures and capabilities. Wasm’s portability makes it an excellent choice for running AI workloads in such a heterogeneous environment, allowing developers to write their code once and run it on various devices.

  –

  Wasm and AI in the Browser

  Wasm can accelerate AI in the browser context as well. It opens up possibilities for running complex AI models directly in the browser, allowing for real-time AI applications such as image recognition, natural language processing, and predictive modeling to run efficiently without the need for server-side computation.

• Decentralized Computing
  With the advent of blockchain technologies and decentralized computing, there is a growing need for efficient, secure, and platform-independent computation models. Wasm’s platform-agnostic nature in combination with its sandboxed execution environment make it an ideal candidate for this use case. Wasm could potentially enable smart contracts execution or complex computations on decentralized platforms, opening up new possibilities for IoT applications in a decentralized context.
• Heterogeneous Computing
  In the future, IoT devices will be increasingly heterogeneous, involving a mix of CPUs, GPUs, and other specialized hardware. The need for a common runtime that can efficiently use these diverse resources will be more critical than ever. Wasm, with its portable and efficient nature, could provide a unified platform for executing code across this heterogeneous hardware, unlocking new possibilities for IoT applications.
• Advanced Robotics
  Wasm’s high performance and real-time capabilities could make it suitable for advanced robotics applications. Whether controlling robotic movements with precision, processing sensor data in real time, or running complex navigation algorithms, Wasm could be instrumental in pushing the boundaries of what is possible in robotics.