Introducing WASM in INT mainnet 4.0


INT mainnet 4.0 is compatible with both EVM and WASM virtual machines. This article introduces the benefits of WASM, WASM-related issues during development and how we solved them.


WASM, known as WebAssembly, is a new encoding method that can run in modern browsers. As a low-level assembly language, WASM has a compact binary format that can run close to native performance and provides a compilation target for languages such as C/C++ so that they can run on the Web. WASM is also a standard for web browsers developed by the W3C WebAssembly Community Group (including Google and Mozilla), and is supported by major browser manufacturers.

For web platforms, WASM provides a way for code written in a variety of languages to run on the web at near-native speed. The three major tech giants — Google, Apple, and Microsoft — also support WASM. Programs written in other languages (such as C, C++, and Java) can be compiled into WASM bytecode. In this case, client software that could not be run this way before can be run on the Web.

Why did INT choose WASM?

WASM uses binary encoding, which has superior performance during program execution. Binary-encoded text takes up less storage space compared to text-heavy languages, effectively reducing our storage costs. Additionally, WASM supports multiple languages so we can use C/C++/RUST/Go and other languages to write smart contracts and compile them into WASM format bytecode. This means INT can be compatible with all programs written with high level languages. The application layer of INT will be richer and the barrier of entry will be low, making development accessible to more developers. Additionally, WASM bytecode can be compiled into machine code before being executed, as well as being directly executable by the WASM interpreter. By supporting WASM, we can widen the possibilities for INT.

What innovations has INT made based with WASM?

  • Gas fee collection

INT charges for each instruction executed by WASM as needed. When the GAS fee for contract execution reaches the limit requested by the caller, the WASM virtual machine automatically terminates the continuation of the contract.

  • System call interface

INT provides several types of system call interfaces:

Some interfaces of the Libc standard library: mainly functions related to memory operations, such as malloc and free. Because the WASM virtual machine serves as the host environment for the execution of WASM contracts, it is necessary to allocate and manage the virtual memory that the contract runs.

Blockchain-related interfaces: To facilitate WASM contracts to access blockchain-related information, INT provides interfaces for storage and reading, account transfer, event triggering, and transaction information.

Library: Provides BigInt and JSON data functions to help contract developers.

  • Memory management

Web Assembly provides memory management to handle character strings and other complex data types, and the memory is an array of bytes that grows over time, as defined by WASM.

Therefore, INT’s WASM virtual machine creates a memory instance of the contract’s imported memory and initializes the contents of the corresponding data segment before executing the contract.

INT uses the Buddy partner algorithm to manage the running memory of the WASM contract. The default initial memory size is 64KB, and the maximum size is 256KB.

  • Simplify contract development

Smart contracts play a role as the business carriers of the blockchain system and will add value to the INT network. One of INT’s aims is to reduce development threshold and simplify the development process so that more enterprises can migrate their business applications to the INT system.

Solving problems after introducing WASM

During internal testing of contract development, we found that a memory leak occurred after introduction of the WASM virtual machine. Since the underlying architecture of INT is implemented using the “go” language, when the contract accesses the underlying native method through the system call interface, the data returned by the underlying method is stored in the linear memory of WASM. Since this memory is not allocated by the developer through malloc, this resulted in the memory leak. Additionally, the bottom layer restricts the upper limit of memory to 256KB, which will cause a contract with complex functions to fail at run time because the upper limit of memory is exceeded. The INT tech team have adopted RAII and SharedPtr in their SDK, which no longer exposes the original memory address, but returns temporary objects on the stack, which solves the memory leak problem.

This concludes our summary of the development with WASM. We will work on more technical articles to outline new developments with mainnet 4.0 in the near future.