v0.32.0 - 2024-05-28

Note:

• This release is the culmination of months of research, development and QA
  with a new execution engine utilizing register-based IR at its core boosting
  both startup and execution performance to new levels for the Wasmi interpreter.
• This release is accompanied with an article that presents some of the highlights.

Added

• Added a new execution engine based on register-machine bytecode. (#729)
  • The register-machine Wasmi Engine executes roughly 80-100% faster and
    compiles roughly 30% slower according to benchmarks conducted so far.
• Added Module::new_unchecked API. (#829)
  • This allows to compile a Wasm module without Wasm validation which can be useful
    when users know that their inputs are valid Wasm binaries.
  • This improves Wasm compilation performance for faster startup times by roughly 10-20%.
• Added Wasm compilation modes. (#844)
  • When using Module::new Wasmi eagerly compiles Wasm bytecode into Wasmi bytecode
    which is optimized for efficient execution. However, this compilation can become very
    costly especially for large Wasm binaries.
  • The solution to this problem is to introduce new compilation modes, namely:
    • CompilationMode::Eager: Eager compilation, what Wasmi did so far. (default)
    • CompilationMode::LazyTranslation: Eager Wasm validation and lazy Wasm translation.
    • CompilationMode::Lazy: Lazy Wasm validation and translation.
  • Benchmarks concluded that
    • CompilationMode::LazyTanslation: Usually improves startup performance by a factor of 2 to 3.
    • CompilationMode::Lazy: Usually improves startup performance by a factor of up to 27.
  • Note that CompilationMode::Lazy can lead to partially validated Wasm modules
    which can introduce non-determinism when using different Wasm implementations.
    Therefore users should know what they are doing when using CompilationMode::Lazy if this is a concern.
  • Enable lazy Wasm compilation with:

    let mut config = wasmi::Config::default();
    config.compilation_mode(wasmi::CompilationMode::Lazy);

  • When CompilationMode::Lazy or CompilationMode::LazyTranslation and fuel metering is enabled
    the first function access that triggers compilation (and validation) will charge fuel respective
    to the number of bytes of the Wasm function body. (#876)
• Added non-streaming Wasm module compilation. (#1035)
  • So far Wasmi only offered a streaming Wasm module compilation API, however most users
    probably never really needed that. So starting from this version both Module::new and
    Module::new_unchecked are now non-streaming with insane performance improvements of up
    to 80% in certain configurations.
  • For streaming Wasm module users we added Module::new_streaming and Module::new_streaming_unchecked APIs.
• Added Module::validate API. (#840)
  • This allows to quickly check if a Wasm binary is valid according to a Wasmi Engine config.
  • Note that this does not translate the Wasm and thus Module::new or Module::new_unchecked
    might still fail due to translation errors.
• CLI: Added --compilation-mode argument to enable lazy Wasm compilation. (#849)
• Added --verbose mode to Wasmi CLI by @tjpalmer. (#957)
  • By default Wasmi CLI no longer prints messages during execution.
• Added Memory::new_static constructor by @Ddystopia. (#939)
  • This allows to construct a Wasm Memory from a static byte array
    which is especially handy for certain embedded use cases.
• Added LinkerBuilder type. (#989)
  • Using LinkerBuilder to create new Linkers with the same set of host functions is a lot more
    efficient than creating those Linkers the original way. However, the initial LinkerBuilder
    construction will be as inefficient as building up a Linker previously.
• Added EnforcedLimits configuration option to Config. (#985)
  • Some users want to run Wasm binaries in a specially restricted or limited mode.
    For example this mode limits the amount of functions, globals, tables etc. can be defined
    in a single Wasm module.
    With this change they can enable this new strict mode using

    let mut config = wasmi::Config::default();
    config.engine_limits(wasmi::EnforcedLimits::strict());

    In future updates we might relax this to make EnforcedLimits fully customizable.
• Added EngineWeak constructed via Engine::weak. (#1003)
  • This properly mirrors the Wasmtime API and allows users to store weak references to the Engine.
• Added no-hash-maps crate feature to the wasmi crate. (#1007)
  • This tells the wasmi crate to avoid using hash based data structures which can be beneficial for
    running Wasmi in some embedded environments such as wasm32-unknown-unknown that do not support
    random sources and thus are incapable to spawn hash maps that are resilient to malicious actors.
  • Note that Wasmi has always avoided using hash map based data structures prior to this change so
    not enabling this new crate feature kind of acts as an optimization.
• Added Default implementation for Store<T> where T: Default. (#1031)
  • This mostly serves as a convenient way to create a minimal Wasmi setup.
• Added WasmTy implementations for f32 and f64 Rust primitives. (#1031)
  • This is convenience for Linker::func_wrap calls that take those primitives as arguments.
    Before this change users had to use F32 and F64 instead which is a bit cumbersome.

Changed

• Minimum Rust version set to 1.77. (#961)
• CLI: Enabled Wasm tail-calls and extend-const proposals by default. (#849)
  • We expect those Wasm proposals to be stabilized very soon so we feel safe to enable them by default already.
• Improved Debug and Display impls for NaNs of Wasm f32 and f64 values.
  • They now show nan:0x{bytes} where {bytes} is their respective raw bytes.
• Implement Sync for ResumableInvocation and TypedResumableInvocation. (#870)
• Properly mirror Wasmtime's fuel API. (#1002)
• Renamed some Wasmi items to improve its Wasmtime mirroring. (#1011)
• Improved Wasmtime API mirror for Store fuel. (#1002)
• Enabled Config::tail_call and Config::extended_const by default. (#1031)
  • Those Wasm proposals have been moved to phase 4 for many months now.

Removed

• Removed the stack-machine bytecode based Wasmi Engine backend. (#818)
  • The new register-machine bytecode based Wasmi Engine is more promising
    and the Wasmi team does not want to maintain two different engine backends.
• Removed FuelConsumptionMode from Config. (#877)
  • FuelConsumptionMode was required to differentiate between lazy and eager fuel consumption.
    This was necessary due to how lazy fuel consumption was implemented in that it would pre-charge
    for instruction execution were the exact amount of required fuel was not possible to determine
    at compilation time. Examples are memory.grow and table.copy instructions. The linked PR
    improved lazy fuel consumption to no longer pre-charge and instead pre-check if the operation
    is going to succeed and only charge fuel in that case.

Dev. Note

• Added execution fuzzing and differential fuzzing.
  • PRs: #832, #833
  • Both fuzzing strategies are applied on each commit in our CI pipeline.
• Updated CI jobs to use dtolnay/rust-toolchain instead of actions-rs because the latter was deprecated. (#842)

v0.31.2 - 2024-01-24

Fixes

• Fixes a Sync impl bug in wasmi_arena.

v0.31.1 - 2023-12-01

Fixes

• CRITICAL: Fixed a critical vulnerability in the Wasmi engine executor.
  • The bug causes an out of bounds buffer write when calling or resuming
    a Wasm function with more than 128 parameters from the host side.
  • Affected users:
    • Users of Wasmi that use functions with more than 128 parameters
      and call those Wasm functions from their own host side. This is
      a very unlikely scenario since functions with such a high number
      of parameters are rather rare.
    • Users of Wasmi that allow external users to call Wasm functions
      with more than 128 parameters from the host side. This is a serious
      attack vector that is enabled by this vulnerability and which this
      fix closes.
  • Special note: Users of the pallet_contracts such as Polkadot are not
    affected by this vulnerability since host to Wasm function calls with
    more than 128 parameters is not possible.
  • Special thanks to Stellar Development Foundation for disclosing this bug to us.

v0.31.0 - 2023-07-31

Added

• Added ResourceLimiter API known from Wasmtime. (#737)
  • This API allows to limit growable Wasm resources such as Wasm tables and linear memories.
  • Special thanks to Graydon Hoare for contributing this feature!

Fixes

• Fixed a bug were Module::len_globals internal API returned length of linear memories instead. (#741)

Changed

• Removed intx crate dependency. (#727)
  • The dependence on the intx crate was accidental and not really required at any time.
• Optimized f64.const instructions for f64 constant values that can losslessly be encoded as 32-bit f32 value. (#746)

Dev. Note

• We now publish and record graphs of benchmarks over time. (#740)
  • This allows wasmi developers to better inspect performance changes over longer periods of time.
• Updated dev. dependencies:
  • criterion 0.4.0 -> 0.5.0
  • wast 0.52.0 -> 0.62.0

v0.30.0 - 2023-05-28

• Optimized wasmi bytecode memory consumption. (#718)
  • This reduced the memory consumption of wasmi bytecode by organizing the instructions
    into so-called instruction words, effectively reducing the amount of bytes required per
    wasmi instruction 16 bytes to 8 bytes.
    There was an experiment with 4 bytes but experiments confirmed that 8 bytes per instruction
    word was the sweetspot for wasmi execution and translation performance.
  • This did not affect execution performance too much but we saw performance improvements
    for translation from Wasm to wasmi bytecode by roughly 15-20%.
• Optimized call and return_call for Wasm module internal calls. (#724)
  • wasmi bytecode now differentiates between calls to Wasm module internal functions
    and imported functions which allows the wasmi bytecode executor to perform the common
    internal calls more efficiently.
  • This led to an execution performance improvement across the board but especially for
    call intense workloads of up to 30% in some test cases.

v0.29.0 - 2023-03-20

Added

• Added support for extended-const Wasm proposal. (#707)
• Added fuel consumption modes. (#706)
  • This allows eager and lazy fuel consumption modes to be used which
    mainly affects bulk operations such as table.copy and memory.grow.
    Eager fuel consumption always consumes fuel before a bulk operation for the
    total amount independent of success or failure of the operation whereras
    lazy fuel consumption only consumes fuel for successful executions.

Changed

• Normalize fuel costs of all instructions. (#705)
  • With this change most instructions cost roughly 1 fuel upon execution.
    This is more similar to how Wasmtime deals with fuel metered instruction costs.
    Before this change wasmi tried to have fuel costs that more closely mirror
    the computation intensity of the respective instruction according to benchmarks.

v0.28.0 - 2023-03-01

Added

• Added support for the tail-call Wasm proposal. (#683)
• Added support for Linker defined host functions. (#692)
  • Apparently this PR introduced some performance wins for the Wasm target according to our tests.
    This information shall be taken with a grain of salt since we are not sure why those performance
    improvement occured since the PR's functionality is orthogonal to Wasm engine performance.
  • Required precursor refactoring PR: #681

Changed

• The wasmi_wasi crate now more closely mirrors the wasmtime_wasi crate API. (#700)

Internal

• Refactor the wasmi Wasm engine to handle Wasm calls and returns in its core. (#694)
  • This improved performance of Wasm function calls significantly at the cost of host function call performance.
  • Also this seemed to have impacts Wasm target performance quite positively, too.
• The Store now handles Wasm functions and host functions separately. (#686)
  • This allows to store Wasm functions into the StoreInner type which was an important
    step towards the major refactoring in (#694)
  • It was expected that host function call performance would degrade by this PR but our tests
    actually showed that the opposite was true and Wasm target performance was improved overall.
• Introduce ValueStackPtr abstraction for the wasmi engine core. (#688)
  • This change significantly improved performance especially on the Wasm target according to our tests.
• Optimize memory.{load,store} when reading or writing single bytes. (#689)
  • The performance wins were more modest than we hoped but still measurable.
• Use StoreContextMut<T> instead of impl AsContextMut in the wasmi engine core. (#685)
  • This is a simple refactoring with the goal to make the Rust compiler have a simpler job at
    optimizing certain functions in the engine's inner workings since StoreContextMut provides
    more information to the compiler.

v0.27.0 - 2023-02-14

Added

• Added support for fuel metering in the wasmi CLI. (#679)
  • Users can now specify an amount of fuel via --fuel N to commit for the execution.
    Upon success the wasmi CLI will display the total amount of consumed and remaining fuel.

Fixed

• Fixed a bug that wasmi CLI did not preserve the WASI exit status. (#677)
  • Thanks to YAMAMOTO Takashi @yamt for reporting the issue.
• The wasmi CLI now properly displays exported functions if --invoke x was provided and x was not found. (#678)
• Applied minor fixes to Config docs. (#673)

Changed

• Defer charging fuel for costly bulk memory and bulk table operations. (#676)
  • Note that the check to assert that enough fuel is provided for these costly
    operation is still happening before the actual computation and only the charging
    is deferred to after a successful run. The reason behind this is that all the affected
    operations fail fast and therefore should not cost lots of fuel in case of failure.

v0.26.1 - 2023-02-13

Fixed

• Fixed a bug where resuming a resumable function from a host function with more outputs than
  inputs could lead to incorrect behavior or runtime panics. (#671)
  • Thanks to Pierre Krieger (tomaka) for reporting and crafting an initial minimal test case.

v0.26.0 - 2023-02-11

Added

• wasmi CLI: Add WASI support. (#597)
  • Big shoutout to Onigbinde Oluwamuyiwa Elijah for contributing this to wasmi!
• Add built-in support for fuel metering. (#653)
  • This allows to control the runtime of Wasm executions in a deterministic fasion
    effectively avoiding the halting problem by charging for executed instructions.
    Not using the feature will not affect the execution efficiency of wasmi for users.
• Add Pages::checked_sub method. (#660)
• Add Func::new constructor. (#662)
  • This allows to create Func instances from closures without statically known types.

Changed

• Update to wasmparser-nostd version 0.100.1. (#666)

Internal

• Clean up and reorganization of the wasmi_cli crate. (#655)
• Refactoring of internal host call API. (#664)