#finite #execution-time #cheating #scale #deterministic #limit #space #webassembly #limits #runtime-agnostic


Guarantee deterministic limits on execution time and space resources made available to the WebAssembly programs in a runtime-agnostic way

4 releases (2 breaking)

0.3.1 Mar 15, 2023
0.3.0 Jan 31, 2023
0.2.0 Jan 27, 2023
0.1.0 Jan 16, 2023

#353 in WebAssembly

Download history 16/week @ 2023-01-11 7/week @ 2023-01-18 50/week @ 2023-01-25 31/week @ 2023-02-01 23/week @ 2023-02-08 40/week @ 2023-02-15 8/week @ 2023-03-01 19/week @ 2023-03-08 54/week @ 2023-03-15 86/week @ 2023-03-22

167 downloads per month


14K SLoC

OCaml 11K SLoC // 0.0% comments Rust 3.5K SLoC // 0.1% comments Batch 75 SLoC


Cheating a little to solve the halting problem at scale

Guarantee deterministic limits on execution time and space resources made available to the WebAssembly programs in a runtime-agnostic way.


This projects provides a couple things:

  • Ammendments to the WebAssembly core module specification describing the changes to the execution model such that the resource use is kept track of and limits are enforced;
  • Analyses that inspect a given WebAssembly module and produce the information necessary to enforce the limits based on the amended execution model;
  • A test suite validating the implementation of analyses against a modified reference WebAssembly interpreter.

The results of the provided analyses can be utilized quite flexibly: to instrument the WASM code; to augment the machine code generated during compilation of the WASM code; to enforce the resource limits at the interpreter runtime; or some other way, thus achieving the portability properties of this project.

Using finite-wasm

The test suite implements a rudimentary WebAssembly module transformation pass. The intent is for it to be just enough to validate the properties of the analyses against the reference interpreter, but it can definitely be taken as a base and adapted into a full production-grade transformation. This is probably the best way to start with.

However this approach may prove to be less than satisfactory performance wise. Transforming a WASM module will require parsing it, modifying it and then serializing it again. While parsing the WASM module at least twice may be be unavoidable, the analyses are constructed such that modification and re-serialization of the modules is not required.


use finite_wasm::{wasmparser as wp, prefix_sum_vec};

struct MySizeConfig;
impl finite_wasm::max_stack::SizeConfig for MySizeConfig {
    fn size_of_value(&self, ty: wp::ValType) -> u8 {
        use wp::ValType::*;
        match ty {
            I32 => 4,
            I64 => 8,
            F32 => 4,
            F64 => 8,
            V128 => 16,
            FuncRef => 32,
            ExternRef => 32,

    fn size_of_function_activation(
        locals: &prefix_sum_vec::PrefixSumVec<wp::ValType, u32>,
    ) -> u64 {
        u64::from(locals.max_index().map(|&v| v + 1).unwrap_or(0))

macro_rules! define_fee {
    ($(@$proposal:ident $op:ident $({ $($arg:ident: $argty:ty),* })? => $visit:ident)*) => {
            fn $visit(&mut self $($(,$arg: $argty)*)?) -> Self::Output { 1 }

struct MyGasConfig;
impl<'a> wp::VisitOperator<'a> for MyGasConfig {
    type Output = u64;

fn analyze_module(wasm_code: &[u8]) -> finite_wasm::AnalysisOutcome {
        .expect("something went wrong!")


This project is licensed under the MIT or Apache-2.0 license.


~143K SLoC