# Efficient Data Exchange between WebAssembly Modules
## 2 Background  
The development of WebAssembly began in 2015, drawing inspiration from ASM.js and NaCl. WASM's primary goal was to enable web browser applications to achieve performance levels comparable to native applications [12]. WASM is supported by all major web browsers, such as Chrome, Firefox, Safari, and Edge, to ensure consistent execution across various browser environments.  
WASM is a virtual instruction set architecture (ISA), consisting of a set of instructions, memory, and a system for communicating with the external environment, and it is executed by a virtual machine (VM). The interaction between the VM and the module can follow certain patterns. As it is a binary format, the WebAssembly Text Format (WAT) was also created, where instructions are written in text, in a more understandable way for humans. The VM, also referred to as \"runtime\", is responsible for executing WASM, which is either compiled or interpreted. The bytecode must be loaded and validated to ensure functionality and compatibility with supported extensions. Generally, there are three execution strategies: interpreted; Just-In-Time (JIT); and Ahead-Of-Time (AOT). The operating mode can affect Karmem, with only AOT being considered due to its superior runtime performance. By definition, WASM only allows access to information within an isolated and unique memory for each module, which makes it impossible to read the memory regions of other modules. Furthermore, communication with the external environment is conducted through imported functions exposed by the VM.  
For a module to communicate with the external environment, it is necessary for it to import functions, and for another module to export those functions. This is the basic operating principle, like a dynamic-link library (DLL). Conversely, the opposite is also possible: the module can be called and utilized by the VM.  
The bytecode's design also addresses the challenge of data transmission over the internet by emphasizing a compact size to allow faster parsing and compilation without the need to download the entire file. This is because bytecode lacks instructions and native support for AES-NI. The WASM bytecode was designed to serve as a unified format, capable of execution across diverse processor architectures, operating systems, and various browsers. Thus, the instructions and operations available in WASM are generally common to all platforms or are virtually possible. WASM extensions introduce additional instructions, some of which align with the introduction of instructions by processors. New instructions are regularly integrated [13], thereby enabling native software to achieve faster execution for specific tasks, while WASM may not have this advantage.  
Like JS, this technology runs in its own isolated sandbox. WASM is restricted from accessing information and data from other addresses or programs, and it cannot violate the constraints imposed by the browser, including cross-origin limitations. Its behavior is intended to be highly predictable and deterministic, maintaining consistency across all architectures. This requirement is more stringent than mere portability; WASM outlines specific contexts that might lead to non-deterministic behavior [14]. Examples of such scenarios include the use of shared memory, multiple threads, or attempts to allocate additional memory. Its capability to deliver near-native performance, portability, language independence, and security has made WASM a versatile and powerful technology for web development.