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 attempt 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 type||WasmLib type||Mutable proxy||Immutable proxy|
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 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.