{
"summary": "Deep research harness — fan-out web searches, fetch sources, adversarially verify claims, synthesize a cited report.",
"agentCount": 106,
"logs": [
"Q: Evaluate libriscv (fwsGonzo's C++ RISC-V emulator) and godot-sandbox (the Godot …",
"Decomposed into 6 angles: primary/determinism, metering/sandbox, embeddability/godot-sandbox, performance/JIT, comparative/trustless-VM, reproducible-builds",
"reproducible-builds: 6 results",
"primary/determinism: 6 results",
"performance/JIT: 6 results",
"performance/JIT: 3 novel (3 filtered)",
"embeddability/godot-sandbox: 6 results",
"embeddability/godot-sandbox: 2 novel (4 filtered)",
"comparative/trustless-VM: 6 results",
"comparative/trustless-VM: 3 novel (3 filtered)",
"metering/sandbox: 6 results",
"metering/sandbox: 3 novel (3 filtered)",
"Fetched 23 sources → 101 claims → verifying top 25",
"\"libriscv supports configurable guest virtual-memor…\": 3-0 ✓",
"\"libriscv handles no system calls by default — unha…\": 3-0 ✓",
"\"libriscv supports a hard instruction-count budget …\": 3-0 ✓",
"\"libriscv markets itself as a secure, low-attack-su…\": 3-0 ✓",
"\"The guest invokes the host via the standard RISC-V…\": 3-0 ✓",
"\"libriscv exposes a memory_max configuration parame…\": 3-0 ✓",
"\"libriscv embeds into other C++ host projects via C…\": 3-0 ✓",
"\"The host retains complete discretion over how (or …\": 0-3 ✗",
"\"Performance is 2.5-10x faster than alternatives by…\": 1-2 ✗",
"\"libriscv supports an optional encompassing arena (…\": 3-0 ✓",
"\"libriscv performs instruction counting as its exec…\": 0-3 ✗",
"\"Host-side syscall handlers must be explicitly inst…\": 3-0 ✓",
"\"libriscv syscalls are deny-by-default: any system …\": 3-0 ✓",
"[v0:godot-sandbox supports execution timeout] failed: API Error: Server is temporarily limiting requests (not your usage limit) · Rate limited",
"[v2:godot-sandbox is a Godot engine addon ti] failed: API Error: Server is temporarily limiting requests (not your usage limit) · Rate limited",
"[v0:Deterministic metering must use an expli] failed: API Error: Server is temporarily limiting requests (not your usage limit) · Rate limited",
"\"The host is explicitly under no obligation to perf…\": 3-0 ✓",
"[v2:godot-sandbox supports execution timeout] failed: API Error: Server is temporarily limiting requests (not your usage limit) · Rate limited",
"[v1:godot-sandbox supports execution timeout] failed: API Error: Server is temporarily limiting requests (not your usage limit) · Rate limited",
"\"godot-sandbox supports execution timeout via instr…\": 0-0 (3 abstain) ✗",
"[v0:WebAssembly is only \"mostly\" determinist] failed: API Error: Server is temporarily limiting requests (not your usage limit) · Rate limited",
"[v1:WebAssembly is only \"mostly\" determinist] failed: API Error: Server is temporarily limiting requests (not your usage limit) · Rate limited",
"[v1:Deterministic metering must use an expli] failed: API Error: Server is temporarily limiting requests (not your usage limit) · Rate limited",
"[v0:Floating-point NaN nondeterminism in Was] failed: API Error: Server is temporarily limiting requests (not your usage limit) · Rate limited",
"[v1:Floating-point NaN nondeterminism in Was] failed: API Error: Server is temporarily limiting requests (not your usage limit) · Rate limited",
"[v1:godot-sandbox is a Godot engine addon ti] failed: API Error: Server is temporarily limiting requests (not your usage limit) · Rate limited",
"[v2:WebAssembly is only \"mostly\" determinist] failed: API Error: Server is temporarily limiting requests (not your usage limit) · Rate limited",
"\"WebAssembly is only \"mostly\" deterministic; achiev…\": 0-0 (3 abstain) ✗",
"[v0:godot-sandbox is a Godot engine addon ti] failed: API Error: Server is temporarily limiting requests (not your usage limit) · Rate limited",
"\"godot-sandbox is a Godot engine addon tightly coup…\": 0-0 (3 abstain) ✗",
"[v0:Wasmtime recommends deterministic fuel-b] failed: API Error: Server is temporarily limiting requests (not your usage limit) · Rate limited",
"[v1:Wasmtime recommends deterministic fuel-b] failed: API Error: Server is temporarily limiting requests (not your usage limit) · Rate limited",
"[v2:Floating-point NaN nondeterminism in Was] failed: API Error: Server is temporarily limiting requests (not your usage limit) · Rate limited",
"\"Floating-point NaN nondeterminism in Wasmtime can …\": 0-0 (3 abstain) ✗",
"[v2:Wasmtime recommends deterministic fuel-b] failed: API Error: Server is temporarily limiting requests (not your usage limit) · Rate limited",
"\"Wasmtime recommends deterministic fuel-based inter…\": 0-0 (3 abstain) ✗",
"[v0:Wasmtime's fuel metering provides precis] failed: API Error: Server is temporarily limiting requests (not your usage limit) · Rate limited",
"[v2:Wasmtime's fuel metering provides precis] failed: API Error: Server is temporarily limiting requests (not your usage limit) · Rate limited",
"[v1:Wasmtime's fuel metering provides precis] failed: API Error: Server is temporarily limiting requests (not your usage limit) · Rate limited",
"\"Wasmtime's fuel metering provides precise instruct…\": 0-0 (3 abstain) ✗",
"[v2:Wasmtime's precise fuel metering imposes] failed: API Error: Server is temporarily limiting requests (not your usage limit) · Rate limited",
"[v0:Wasmtime's precise fuel metering imposes] failed: API Error: Server is temporarily limiting requests (not your usage limit) · Rate limited",
"[v2:libriscv supports instruction counting w] failed: API Error: Server is temporarily limiting requests (not your usage limit) · Rate limited",
"[v1:Wasmtime's precise fuel metering imposes] failed: API Error: Server is temporarily limiting requests (not your usage limit) · Rate limited",
"\"Wasmtime's precise fuel metering imposes a signifi…\": 0-0 (3 abstain) ✗",
"[v0:libriscv supports instruction counting w] failed: API Error: Server is temporarily limiting requests (not your usage limit) · Rate limited",
"[v1:libriscv supports instruction counting w] failed: API Error: Server is temporarily limiting requests (not your usage limit) · Rate limited",
"\"libriscv supports instruction counting with a conf…\": 0-0 (3 abstain) ✗",
"\"Deterministic metering must use an explicit per-ba…\": 1-0 (2 abstain) ✗",
"\"Instruction-counting deterministic metering (gas d…\": 3-0 ✓",
"\"The Arm floating-point instructions are determinis…\": 3-0 ✓",
"Verify done: 25 claims → 13 confirmed, 12 killed"
],
"result": {
"question": "Evaluate libriscv (fwsGonzo's C++ RISC-V emulator) and godot-sandbox (the Godot GDExtension that wraps libriscv) as a sandboxed execution target for a peer-to-peer distributed computation system. The system needs to run untrusted, content-addressed compute tasks where the SAME code+input must produce the SAME output bytes on every peer, so results can be memoized by hash and verified by independent re-execution.\n\nAssess libriscv and godot-sandbox specifically on these decision criteria, with concrete mechanics, current (2025-2026) maturity, and primary sources:\n\n1. DETERMINISM: Is libriscv execution bit-exact deterministic across different host hardware/OS (x86-64, arm64)? How is floating-point handled (soft-float vs host FPU, IEEE-754 reproducibility)? Any sources of nondeterminism (uninitialized memory, syscall results, host time)? This is the single most important criterion — without cross-hardware determinism it cannot memoize or verify.\n\n2. RESOURCE METERING / SANDBOXING: Does libriscv support instruction counting / \"fuel\" / execution-budget limits to bound runaway computation? Memory limits (sandboxed guest address space)? Wall-clock timeout? How strong is the isolation (can guest code escape, make syscalls, touch the host)? What is the host<->guest call/syscall ABI and how is it gated?\n\n3. EMBEDDABILITY: libriscv is header-only C++. Can it be embedded as a native addon in a non-Godot host runtime (specifically Bare / Node.js via N-API, or a C ABI)? godot-sandbox is Godot-specific — how coupled is it to the engine, and could libriscv be used standalone? What languages compile to its RISC-V guest (C/C++/Rust/Zig via standard riscv toolchains)?\n\n4. PERFORMANCE: libriscv's interpreter vs binary-translation/JIT modes — throughput vs native, startup/load latency, and the determinism implications of JIT (does binary translation preserve bit-exactness?). How does it compare to WASM runtimes (wasmtime/wasmer) on speed and on fuel-metering overhead.\n\n5. CONTENT-ADDRESSABILITY & REPRODUCIBLE BUILDS: Can a RISC-V ELF binary be built reproducibly (same source -> same bytes -> stable codeHash)? How does this compare to reproducible WASM modules.\n\n6. libriscv vs WASM (wasmtime/wasmer/WAMR) HEAD-TO-HEAD as the executor for trustless distributed compute: determinism guarantees, metering maturity, ecosystem/toolchain, embedding cost, security track record. Which is the better default and in what scenarios is the other preferred? Surface any other contenders used in blockchain/trustless-compute settings (e.g. RISC Zero's RISC-V zkVM, Cartesi's RISC-V Linux, PolkaVM/RISC-V, Fuel/FuelVM, eBPF) and what their choice of ISA says about RISC-V-for-determinism.\n\nPrioritize primary sources (libriscv and godot-sandbox GitHub repos/docs/wiki, fwsGonzo's writeups, benchmarks), honest maturity assessment, and the determinism + metering criteria above all else, since those are what make trustless memoized re-execution possible.",
"summary": "libriscv is a viable sandboxed execution target for trustless distributed compute, with strong, primary-source-confirmed support for the two most critical criteria: fuel-style instruction-count metering (set_max_instructions / simulate with an instruction-limit timeout) and a deny-by-default sandbox (no syscalls unless the host explicitly installs handlers; -ENOSYS otherwise; narrow ECALL ABI; configurable memory_max and address-space arena caps). However, the libriscv project itself makes NO explicit guarantee of bit-exact cross-hardware determinism or IEEE-754 floating-point reproducibility, and has no formal audit — so determinism is plausible-but-unproven from libriscv's own documentation. The strongest determinism evidence comes from an adjacent academic system (DeCl, Stanford, SIB'24/OSDI'25), which establishes that a restricted deterministic instruction subset (including FP) is bit-exact across ARM64 microarchitectures via ISA analysis and fuzzing, and that deterministic native instruction-count metering is far cheaper than WASM metering (~16-21% overhead vs Wasmtime/Cranelift fuel at ~90% and a WASM interpreter at ~1920%). Net: RISC-V/native sandboxing offers a metering-cost advantage and a clean opt-in ABI, but to use libriscv for memoizable re-execution you must yourself restrict the guest to a deterministic instruction subset, pin the FP environment, control the binary-translation/JIT path, and validate cross-hardware bit-exactness — none of which libriscv guarantees out of the box.",
"findings": [
{
"claim": "libriscv provides production-grade fuel-style resource metering: a hard instruction-count budget (set_max_instructions / simulate(limit)) that deterministically halts runaway computation, with detection (instruction_limit_reached) and resumability (reset_instruction_counter).",
"confidence": "high",
"sources": [
"https://github.com/libriscv/libriscv",
"https://github.com/libriscv/libriscv/blob/master/docs/INTEGRATION.md"
],
"evidence": "README shows machine.set_max_instructions(50'000'000ull) and simulate(5'000'000'000ull) running until exit syscall or the instruction counter reaches the limit; instruction_limit_reached() detects timeout, reset_instruction_counter() resumes. The budget is resumable and can be disabled in an 'inaccurate' fast mode (simulate_inaccurate) but is enforced by default. This directly satisfies the 'fuel'/execution-budget criterion for bounding untrusted compute.",
"vote": "3-0"
},
{
"claim": "libriscv provides hard sandbox memory bounds: a memory_max config caps how much memory a guest can consume (lazy physical allocation underneath), and an optional encompassing arena (RISCV_ENCOMPASSING_ARENA / _BITS) bounds the guest's entire address space to a fixed bit-width (e.g. 32 bits = 4GB, 30 bits = 1GB).",
"confidence": "high",
"sources": [
"https://github.com/libriscv/libriscv",
"https://github.com/libriscv/libriscv/blob/master/docs/INTEGRATION.md"
],
"evidence": "README: 'You can limit the amount of (virtual) memory the machine can use' via MachineOptions{.memory_max=...}. INTEGRATION.md: memory_max sets the upper limit a guest can consume and the guest 'may never access memory outside of this area'; physical pages allocated lazily on write. The arena bounds all memory operations to an N-bit space. IMPORTANT caveat from the docs: the arena is currently fully readable/writable and 'should not be used when sandboxing is necessary' (full isolation needs userfaultfd, not yet wired up) — so for untrusted code use memory_max-based isolation, not the arena, for the security boundary.",
"vote": "3-0"
},
{
"claim": "libriscv is a deny-by-default sandbox with a narrow, fully host-controlled syscall ABI: no syscalls are serviced unless the host explicitly installs handlers (install_syscall_handler), unhandled calls return -ENOSYS, and the host is under no obligation to honor any request.",
"confidence": "high",
"sources": [
"https://libriscv.no/docs/concepts/syscalls/",
"https://github.com/libriscv/libriscv/blob/master/docs/SYSCALLS.md"
],
"evidence": "SYSCALLS.md and libriscv.no both state 'Unhandled system calls return -ENOSYS by default' and 'To implement missing system calls, you have to set a handler for it' via machine.install_syscall_handler(number, handler). Even exit(93)/exit_group(94) must be installed. The guest invokes the host purely via the RISC-V ECALL instruction (args in A0-A6, syscall number in A7, return in A0). 'The host system is under no obligation to do anything.' This gives the embedder a small, fully gated host<->guest boundary — exactly what is needed to forbid host time, network, randomness, and any other nondeterminism source in untrusted compute. Convenience batch-installers (e.g. setup_linux_syscalls) exist but require explicit host opt-in.",
"vote": "3-0"
},
{
"claim": "libriscv itself does NOT guarantee bit-exact cross-platform determinism or IEEE-754 floating-point reproducibility, and has no formal third-party audit; it only markets a low-attack-surface (~20k LOC) speculation-safe sandbox.",
"confidence": "high",
"sources": [
"https://github.com/libriscv/libriscv",
"https://github.com/libriscv/libriscv/blob/master/SECURITY.md"
],
"evidence": "README Goals state 'Low attack surface, only 20k LOC' and 'Secure speculation-safe sandbox' but make NO claim of bit-exact cross-host (x86-64/arm64) execution or FP IEEE-754 reproducibility. SECURITY.md likewise mentions no cross-platform determinism, no FP reproducibility, and no formal audit. CRITICAL for the use case: this is the single most important criterion for memoized re-execution, and libriscv's own docs do not promise it. Absence of a guarantee is not evidence of non-determinism, but it means determinism must be established/enforced by the embedder (restrict instruction subset, pin FP rounding/NaN behavior, validate cross-hardware) rather than assumed.",
"vote": "3-0"
},
{
"claim": "A restricted deterministic instruction subset — including floating-point — is empirically bit-exact across different ARM64 hardware, supporting the feasibility of trustless re-execution on RISC-style native sandboxes.",
"confidence": "high",
"sources": [
"https://www.scs.stanford.edu/~zyedidia/docs/papers/decl_sib24.pdf"
],
"evidence": "DeCl (Stanford, SIB'24, also OSDI'25): 'According to our analysis of the Arm ISA, the floating point instructions are deterministic,' corroborated by fuzzing on Apple silicon, Arm Neoverse, Ampere Altra, and QEMU, generating multi-megabyte branchless snapshots and confirming end-state (memory + registers) is consistent across microarchitectures — when restricted to a deterministic subset (excluding CONSTRAINED UNPREDICTABLE, certain atomics, UNDEFINED encodings). NOTE this is about ARM64 native, not libriscv specifically, and is engineering-grade corroboration via fuzzing, not a formal proof. It validates the general principle (deterministic ISA subset + pinned FP env => reproducible end-state) that libriscv's RISC-V interpreter would need to inherit, but does not itself certify libriscv. FP determinism also depends on per-process FPCR config (flush-to-zero, default-NaN, rounding) being initialized identically on all peers.",
"vote": "3-0"
},
{
"claim": "Deterministic native instruction-count metering is dramatically cheaper than WASM metering — a core argument for native/RISC-style sandboxes over WASM in metered trustless compute.",
"confidence": "high",
"sources": [
"https://www.scs.stanford.edu/~zyedidia/docs/papers/decl_sib24.pdf"
],
"evidence": "DeCl (SPEC 2017, Apple M2, ARM64) reports geomean overhead vs native: DeCl timer-based 16.3%, branch-based 21.2% (gas debited at basic-block ends via a reserved meter register), versus iwasm WASM interpreter ~1920% and Wasmtime/Cranelift JIT with fuel metering ~90.0%. Versions: iwasm v1.3.2, Wasmtime v24.0.0. This quantifies a large metering-overhead gap favoring native sandboxing. Caveat: DeCl is a different system (LFI-based native sandbox), not libriscv; libriscv's own interpreter overhead vs native is higher than DeCl's instrumented-native approach, and libriscv's competitive performance story relies on binary translation (whose determinism interaction must be separately verified). The number to take away is the metering-cost comparison, not a direct libriscv-vs-Wasmtime throughput figure.",
"vote": "3-0"
},
{
"claim": "libriscv is cleanly embeddable in non-Godot native hosts: header-only C++ via CMake FetchContent/add_subdirectory, plus a C API (libriscv_capi) for integration from other languages.",
"confidence": "high",
"sources": [
"https://fwsgonzo.medium.com/libriscv-version-1-0-594985712e2e"
],
"evidence": "fwsGonzo's v1.0 writeup: 'Embedding a project with CMake should be really straight-forward. I support both FetchContent and add_subdirectory()' and 'There is now a C API ... CMake to build a new library called libriscv_capi ... presents a public C header. The C API will become more fleshed out over time, but for now it does the job.' For the target architecture (a Bare/Node.js host), this means libriscv could be wrapped as a native addon over its C ABI or C++ API (e.g. via bare-addon / N-API / require-addon). godot-sandbox, by contrast, is the Godot-engine wrapper and is not the right integration path for a non-Godot runtime — libriscv standalone is. Guests can be compiled from C/C++/Rust/Zig via standard riscv toolchains. Maturity caveat: the author explicitly hedges the C API is not yet fully fleshed out.",
"vote": "3-0"
}
],
"caveats": "DETERMINISM IS THE KEY UNPROVEN POINT. libriscv's own documentation does NOT guarantee bit-exact cross-hardware execution or FP IEEE-754 reproducibility (claim 3 above). The strong determinism evidence (claim 4) and the metering-overhead numbers (claim 5) come from DeCl, a SEPARATE academic system (native ARM64 sandbox via LFI), not from libriscv itself — they validate the general RISC/native-deterministic-subset principle but do not certify libriscv. Treat libriscv determinism as 'plausible and likely achievable with discipline' rather than 'guaranteed.'\n\nSEVERAL HEAD-TO-HEAD CLAIMS WERE REFUTED OR UNVERIFIED, leaving real gaps: (a) the claim that libriscv binary translation/JIT bypasses instruction metering (translate_ignore_instruction_limit) was REFUTED 0-3, but so was the counter-claim implicitly — the precise metering behavior under binary translation remains unconfirmed and is critical because JIT could threaten bit-exactness; (b) godot-sandbox's coupling and its own timeout/memory-safety claims went unvoted (0-0), so its standalone-extractability is uncorroborated here; (c) all the Wasmtime determinism/fuel claims (NaN canonicalization, deterministic fuel vs epoch, fuel overhead) were 0-0 unvoted — the WASM side of the head-to-head is weakly sourced in this dataset; (d) the performance claim '2.5-10x faster, 5-50x with binary translation, cross-platform translation without JIT' was REFUTED 1-2, so libriscv throughput claims are unreliable as stated.\n\nSOURCE QUALITY: libriscv claims rest on the official repo, libriscv.no docs, and fwsGonzo's Medium writeup (primary, current to master branch). The determinism + metering-overhead evidence rests on a single peer-reviewed paper (DeCl). No independent benchmark of libriscv-vs-Wasmtime for this specific trustless-compute workload was verified. No formal security audit of libriscv exists.\n\nTIME-SENSITIVITY: API surface (set_max_instructions, memory_max, install_syscall_handler, RISCV_ENCOMPASSING_ARENA) is current master (2025-2026). The arena's lack of full isolation (needs userfaultfd) and the C API's incompleteness are explicitly evolving — re-verify before committing.",
"openQuestions": [
"Does libriscv's binary-translation/JIT mode preserve bit-exact determinism AND continue to enforce the instruction-count budget? The 'translate_ignore_instruction_limit' option and the refuted-but-unresolved metering-under-translation claim mean the interpreter is the only currently-trustworthy deterministic+metered path — but the interpreter is the slow path, undermining the performance argument. Empirical cross-hardware (x86-64 vs arm64) bit-exactness testing of libriscv specifically is required.",
"How does libriscv handle floating-point internally — does its RISC-V FP execution use the host FPU (inheriting host FPCR/rounding/NaN state, which DeCl shows must be pinned identically on all peers) or a soft-float path? Soft-float would give the strongest cross-hardware reproducibility guarantee; this is undocumented in the verified sources and is decisive for the memoization use case.",
"Can a RISC-V ELF guest be built reproducibly (same source -> same bytes -> stable codeHash) with standard riscv toolchains, and how does that compare to reproducible WASM modules? Criterion 5 (content-addressability / reproducible builds) was not covered by any surviving verified claim and needs direct investigation.",
"For the actual target host (Bare/Node.js), what is the real embedding cost and stability of wrapping libriscv's C API/C++ as a native addon, given fwsGonzo's own hedge that the C API 'will become more fleshed out over time'? And how does this compare to embedding a mature WASM runtime (wasmtime/wasmer/WAMR) which already ships first-class language bindings — i.e., is libriscv's metering/determinism edge worth the heavier embedding and self-imposed-determinism burden versus an off-the-shelf metered WASM runtime?"
],
"refuted": [
{
"claim": "The host retains complete discretion over how (or whether) to service any syscall, which is the mechanism enforcing the sandbox boundary against untrusted guest code.",
"vote": "0-3",
"source": "https://libriscv.no/docs/concepts/syscalls/"
},
{
"claim": "Performance is 2.5-10x faster than alternatives by default and 5-50x with binary translation, with optional JIT builds; binary translation works across all platforms without requiring JIT.",
"vote": "1-2",
"source": "https://github.com/libriscv/godot-sandbox/blob/main/README.md"
},
{
"claim": "libriscv performs instruction counting as its execution-budget mechanism, but this counting is NOT performed during binary translation (the translate_ignore_instruction_limit option), meaning the fuel/instruction-limit metering is bypassed in translated/JIT mode and execution must be stopped by another external method.",
"vote": "0-3",
"source": "https://github.com/libriscv/libriscv/blob/master/docs/INTEGRATION.md"
},
{
"claim": "Deterministic metering must use an explicit per-basic-block instruction count (a 'gas' counter in a reserved register decremented and checked at branches), NOT timer interrupts or the hardware PMU instruction counter, because timers/PMU preempt at non-deterministic instruction boundaries and would cause replicas to diverge on side-effecting calls — establishing the design requirement for any memoizable re-execution metering scheme.",
"vote": "1-0",
"source": "https://www.scs.stanford.edu/~zyedidia/docs/papers/decl_sib24.pdf"
},
{
"claim": "godot-sandbox is a Godot engine addon tightly coupled to the engine: it exposes a Sandbox node, loads ELF binaries, and implements its API as Godot syscalls in src/sandbox_syscalls.cpp, with libriscv embedded underneath.",
"vote": "0-0",
"source": "https://github.com/libriscv/godot-sandbox/blob/main/CLAUDE.md"
},
{
"claim": "godot-sandbox supports execution timeout via instruction counting (a metering mechanism to bound runaway computation), and is memory safe.",
"vote": "0-0",
"source": "https://github.com/libriscv/godot-sandbox/blob/main/CLAUDE.md"
},
{
"claim": "WebAssembly is only \"mostly\" deterministic; achieving determinism requires explicit configuration because several language features are inherently nondeterministic by spec.",
"vote": "0-0",
"source": "https://docs.wasmtime.dev/examples-deterministic-wasm-execution.html"
},
{
"claim": "Floating-point NaN nondeterminism in Wasmtime can be eliminated via Cranelift NaN canonicalization, but at a performance cost.",
"vote": "0-0",
"source": "https://docs.wasmtime.dev/examples-deterministic-wasm-execution.html"
},
{
"claim": "Wasmtime recommends deterministic fuel-based interruption (rather than epoch-based) for bounding execution in a reproducible way, providing a metering mechanism for trustless compute.",
"vote": "0-0",
"source": "https://docs.wasmtime.dev/examples-deterministic-wasm-execution.html"
},
{
"claim": "Wasmtime's fuel metering provides precise instruction-execution control at basic-block granularity, implemented via compare-and-conditional-jump checks.",
"vote": "0-0",
"source": "https://github.com/bytecodealliance/wasmtime/issues/4109"
},
{
"claim": "Wasmtime's precise fuel metering imposes a significant runtime performance penalty.",
"vote": "0-0",
"source": "https://github.com/bytecodealliance/wasmtime/issues/4109"
},
{
"claim": "libriscv supports instruction counting with a configurable hard execution budget (e.g. set_max_instructions(50'000'000)), allowing computation to be paused or aborted when an instruction-count limit is reached — providing deterministic 'fuel'-style metering for bounding runaway compute.",
"vote": "0-0",
"source": "https://github.com/fwsGonzo/libriscv"
}
],
"sources": [
{
"url": "https://github.com/libriscv/libriscv",
"quality": "primary",
"angle": "primary/determinism",
"claimCount": 5
},
{
"url": "https://libriscv.no/docs/concepts/syscalls/",
"quality": "primary",
"angle": "primary/determinism",
"claimCount": 4
},
{
"url": "https://github.com/libriscv/godot-sandbox/blob/main/README.md",
"quality": "primary",
"angle": "primary/determinism",
"claimCount": 4
},
{
"url": "https://fwsgonzo.medium.com/libriscv-risc-v-binary-translation-part-2-deb3589375ad",
"quality": "blog",
"angle": "primary/determinism",
"claimCount": 5
},
{
"url": "https://fwsgonzo.medium.com/libriscv-version-1-0-594985712e2e",
"quality": "primary",
"angle": "primary/determinism",
"claimCount": 4
},
{
"url": "https://www.chciken.com/simulation/2023/11/12/fast-floating-point-simulation.html",
"quality": "blog",
"angle": "primary/determinism",
"claimCount": 5
},
{
"url": "https://github.com/libriscv/libriscv/blob/master/docs/INTEGRATION.md",
"quality": "primary",
"angle": "metering/sandbox",
"claimCount": 5
},
{
"url": "https://github.com/libriscv/libriscv/blob/master/docs/SYSCALLS.md",
"quality": "primary",
"angle": "metering/sandbox",
"claimCount": 5
},
{
"url": "https://www.scs.stanford.edu/~zyedidia/docs/papers/decl_sib24.pdf",
"quality": "primary",
"angle": "metering/sandbox",
"claimCount": 5
},
{
"url": "https://github.com/libriscv/godot-sandbox/blob/main/CLAUDE.md",
"quality": "primary",
"angle": "embeddability/godot-sandbox",
"claimCount": 5
},
{
"url": "https://libriscv.no/docs/host_langs/godot_integration/godot_docs/cmake/",
"quality": "primary",
"angle": "embeddability/godot-sandbox",
"claimCount": 3
},
{
"url": "https://libriscv.no/docs/intro/",
"quality": "primary",
"angle": "performance/JIT",
"claimCount": 4
},
{
"url": "https://docs.wasmtime.dev/examples-deterministic-wasm-execution.html",
"quality": "primary",
"angle": "performance/JIT",
"claimCount": 5
},
{
"url": "https://github.com/bytecodealliance/wasmtime/issues/4109",
"quality": "primary",
"angle": "performance/JIT",
"claimCount": 5
},
{
"url": "https://github.com/fwsGonzo/libriscv",
"quality": "primary",
"angle": "comparative/trustless-VM",
"claimCount": 5
},
{
"url": "https://forum.polkadot.network/t/announcing-polkavm-a-new-risc-v-based-vm-for-smart-contracts-and-possibly-more/3811",
"quality": "primary",
"angle": "comparative/trustless-VM",
"claimCount": 5
},
{
"url": "https://github.com/cartesi/machine-emulator",
"quality": "primary",
"angle": "comparative/trustless-VM",
"claimCount": 5
},
{
"url": "https://github.com/risc0/risc0/issues/1481",
"quality": "primary",
"angle": "reproducible-builds",
"claimCount": 3
},
{
"url": "https://docs.rs/risc0-build/latest/risc0_build/",
"quality": "primary",
"angle": "reproducible-builds",
"claimCount": 3
},
{
"url": "https://github.com/project-oak/oak/issues/865",
"quality": "primary",
"angle": "reproducible-builds",
"claimCount": 3
},
{
"url": "https://github.com/rust-lang/rust/issues/117597",
"quality": "forum",
"angle": "reproducible-builds",
"claimCount": 3
},
{
"url": "https://docs.internetcomputer.org/building-apps/best-practices/reproducible-builds",
"quality": "primary",
"angle": "reproducible-builds",
"claimCount": 5
},
{
"url": "https://reproducible-builds.org/docs/deterministic-build-systems/",
"quality": "primary",
"angle": "reproducible-builds",
"claimCount": 5
}
],
"stats": {
"angles": 6,
"sourcesFetched": 23,
"claimsExtracted": 101,
"claimsVerified": 25,
"confirmed": 13,
"killed": 12,
"afterSynthesis": 7,
"urlDupes": 9,
"budgetDropped": 4,
"agentCalls": 106
}
}
}