​

WebAssembly Runtime

• Deterministic Execution: Contracts can be executed and interrupted based on gas limits and memory constraints, ensuring predictable behavior.
• Efficient Bytecode: WASM offers a portable and efficient bytecode format for the Sigil runtime.

​

WebAssembly Component Model

• WIT Signatures: Every Sigil contract includes a WebAssembly Interface Type (WIT) “header” file that explicitly exports all public functions in a standardized, high-level type language. This makes contracts more accessible to developers and tooling.
• Runtime Validation: The WIT file is compiled into the WASM code, allowing the Sigil runtime to extract and validate the contract’s interface at runtime and for tooling integration.
• Future Component Imports: The Component Model lays the foundation for importing other components for code reuse, though cross-contract calls currently use a foreign call primitive in an isolated execution context.
• WAVE Format: Sigil uses the WebAssembly Value Expression (WAVE) format for passing arguments and returning results, standardizing value types across languages compiled to WASM.
• Exported Function Conventions: Exported functions in WIT files follow standard WIT types, with two additional conventions:
  • Hook-Based Execution: Functions with specific names serve as hooks and are called under certain conditions and not explicitly by a user.
  • Execution Context: The first argument of every function is an execution context, defining its behavior and access rights.

​

Key Features

​

Hooks

• init Hook: Runs when a contract is published and is primarily for setting initial storage values or perform data migrations for contract upgrades. It currently supports arbitrary contract code execution.
• fallback Hook: Accepts WAVE arguments and returns WAVE results. This hook is called when no other function matches the call, and it is primarily used to implement proxy contracts for versioning in userspace, similar to how proxying is implemented in Solidity.

​

Execution Contexts

• proc (Procedure) Context:
  • Can read and write to storage
  • Callable when submitting blockchain transactions
• view Context:
  • Read-only access to storage
  • Callable via the API exposed by Kontor nodes
• fall (Fallback) Context:
  • Used exclusively for the fallback hook
  • Can be converted into other context types

​

Primitives

1. Signer Access: Available only in proc contexts, allows access to the signer of the current transaction
2. Cross-Contract Calls: A function for calling other contracts, contributing to the gas expenditure of the transaction
3. Storage Functions:
   • get and set operations for primitive types (e.g., strings, u64), parameterized by a key or path
   • Checking if a key exists in storage
   • Regex-based path matching

​

Library Code and SDK

• Traits for Runtime Primitives: The runtime implements traits for all primitives, allowing pure Rust libraries (including Sigil’s standard library) to operate independently of the runtime. Developers can implement in-memory versions of these traits for testing without relying on the Sigil runtime.
• Ordinary Rust Programming: Rust macros make Sigil programming feel simple and familiar.
• Private Helper Functions: Non-exported functions (without WIT signatures) compile to regular WASM instructions, behaving like standard Rust functions.

​

Storage and Versioning

• Primitive Operations: Storage uses path-keyed get and set operations for basic types (e.g., integers, booleans, strings).
• ORM-like Macros: The SDK provides macros for declaring persistent data types, including records, enums, non-recursive sum types, and built-in Map types. Nested fields can be accessed (e.g., foo.bar.baz) without retrieving entire structures.
• Isolation: Each contract’s storage is isolated, with no equivalent to Ethereum’s delegatecall. This simplifies the mental model, treating foreign contract calls like web API calls.
• Gas Tracking: The design avoids complex operations (e.g., SQL-like joins) to make gas consumption intuitive.
• Versioning: Sigil supports userspace versioning through the fallback hook and proxy contracts. Developers can implement advanced upgrade mechanisms, such as DAO-like voting for safe upgrades, avoiding reliance on key-based upgrades that risk rug pulls. External calls to proxy contracts appear as standard contract calls, enhancing transparency.

​

Error Handling

• Error Types: Errors are represented as a custom Error type, which can be returned from functions.
• Error Propagation: Errors can be propagated up the call stack using the ? operator.
• Error Handling: Results can be handled using match expressions over Ok and Err variants or with the many other error handling strategies available in Rust.

​

Safety

• Check: Verify conditions (e.g., sufficient funds)
• Effect: Update storage (e.g., deduct funds)
• Interaction: Perform external operations (e.g., cross-contract calls)

check_sufficient_funds(); // Check
transfer_funds_in_storage(); // Effect
do_external_operations(); // Interaction