Skip to main content

WasmLib Data Types

You will need to manipulate data with your smart contracts. We distinguish two groups of predefined data types that can be used in schema definition files. The WasmLib implementations for each supported programming language provide full support for these predefined data types. Each predefined data type can be (de)serialized as byte string or as human-readable text string.

Basic Value Data Types

These are mostly simple built-in scalar data types as provided by most programming languages. Each integer data type has a clearly defined storage size. The schema tool will try to use the closest matching built-in data type when generating code for a specific language.

  • BigInt - An arbitrary-length unsigned integer.
  • Bool - An 8-bit boolean value (0 or 1).
  • Bytes - An arbitrary-length byte array.
  • Int8 - 8-bit signed integer value.
  • Int16 - 16-bit signed integer value.
  • Int32 - 32-bit signed integer value.
  • Int64 - 64-bit signed integer value.
  • String - An arbitrary-length UTF-8 encoded string value.
  • Uint8 - 8-bit unsigned integer value.
  • Uint16 - 16-bit unsigned integer value.
  • Uint32 - 32-bit unsigned integer value.
  • Uint64 - 64-bit unsigned integer value.

ISC-specific Value Data Types

These are ISC-specific value data types that are needed in the ISC sandbox function calls. More detailed explanations about their specific uses can be found in the ISC documentation . WasmLib provides its own implementations for each of the ISC value data types.

  • Address - A 33-byte encoded Tangle address.
  • AgentID - An ISC Agent ID (Address + Hname).
  • ChainID - A 32-byte ISC Chain ID.
  • Hash - A 32-byte hash value.
  • Hname - A 4-byte unsigned integer hash value derived from a name string.
  • NftID - A 32-byte ISC NFT ID.
  • RequestID - A 34-byte ISC transaction request ID.
  • TokenID - A 38-byte ISC token ID.

Full Matrix of WasmLib Types

WasmLib implements a full set of value proxies for each predefined value type that provide access to data on the ISC host. But there is one aspect of this data that we have not considered yet. Some data provided by the host is mutable, whereas other data may be immutable. To facilitate this distinction, each value proxy type comes in two flavors that reflect this, and make sure that the data can only be used as intended.

The rule is that from an immutable container you can only derive immutable container and value proxies. The referenced data can never be changed through immutable proxies. Separating these constraints for types into separate value proxy types allows the use of compile-time type-checking to enforce these constraints. To guard against client code that tries to bypass them, the ISC sandbox will also check these constraints at runtime on the host.

ISC typeWasmLib typeMutable proxyImmutable proxy
Bytesbyte arrayScMutableBytesScImmutableBytes
Int88-bit signedScMutableInt8ScImmutableInt8
Int1616-bit signedScMutableInt16ScImmutableInt16
Int3232-bit signedScMutableInt32ScImmutableInt32
Int6464-bit signedScMutableInt64ScImmutableInt64
StringUTF-8 stringScMutableStringScImmutableString
Uint88-bit unsignedScMutableUint8ScImmutableUint8
Uint1616-bit unsignedScMutableUint16ScImmutableUint16
Uint3232-bit unsignedScMutableUint32ScImmutableUint32
Uint6464-bit unsignedScMutableUint64ScImmutableUint64

The consistent naming makes it easy to remember the type names. Bool, Bytes, String, and the integer types are the odd ones out. They are implemented in WasmLib by the closest equivalents in the chosen WasmLib implementation programming language.

The schema tool will automatically generate the proper (im)mutable proxies from the schema definition. For example, View functions will only be able to access the state storage map through immutable proxies. The same goes for the params map that was passed into a Func or View, and for the results map that was returned from a call to a Func or View.

In the next section we will show how use these predefined types to create user-defined Structured Data Types.