Skip to main content

Call Context

Due to the sandboxed nature of Wasm code, it needs a host which runs the Wasm Virtual Machine (VM) that is able to load and execute the Wasm code. The host also provides the Wasm code with restricted access to the host environment. These restrictions make the host environment itself sandboxed as well. Smart contracts will only be able to call certain environment functionality, depending on the call context.

We distinguish between two types of smart contract function calls:

  • Func, which allows full mutable access to the smart contract state, and always results in a state update. Funcs can be initiated through on-ledger and off-ledger requests. A call to a Func is only complete once the associated state update has been registered in the ledger (Tangle).
  • View, which allows only limited, immutable access to the smart contract state, and therefore does not result in a state update. Views are always initiated through off-ledger function calls. Since they do not require a state update on the ledger they can be used to efficiently query the current state of the smart contract.

To support this function call type distinction, Func and View functions each receive a separate, different call context through WasmLib. Only the functionality that is necessary for their implementation can be accessed through their respective WasmLib contexts, ScFuncContext and ScViewContext. ScViewContext provides a limited, immutable subset of the full functionality provided by ScFuncContext. By having separate context types, compile-time type-checking can easily be used to enforce these usage constraints.

Smart Contract Setup

An important part of setting up a smart contract is defining exactly which Funcs and Views are available and informing the host about them through WasmLib. The host will have to be able to dispatch requested function calls to the corresponding smart contract code and will have to apply any restrictions necessary to prevent Views from accidentally accessing full Func functionality.

Another important part is to define for each function exactly what parameters and return values are expected/available, if any. The ISC stores parameter, state, and result values in simple dictionaries, with both keys and values being arbitrary byte strings. Normally, programming languages provide a much richer set of data types, which means that these data types will need to be serialized and deserialized correctly and consistently. WasmLib provides a rich set of (de)serialization functions specifically for this purpose

Even though it is definitely possible for a contract creator to directly use WasmLib to achieve his goals, we decided to provide a Schema Tool, which can be used to automatically generate and update the entire smart contract framework code in the desired language in a consistent and type-safe way.

In the next section we will introduce this smart contract Schema Tool.