Files
xahaud/include/xrpl/protocol
tequ 0e8cedc7a9 feat(hook): add Wasmtime engine backend behind featureWasmtimeEngine amendment
Add Wasmtime v44.0.1 as a second WebAssembly execution engine, selectable at runtime via the new featureWasmtimeEngine Amendment. When the Amendment is enabled, hook execution and WASM validation switch from WasmEdge to Wasmtime.
sfHookInstructionCount changes semantics to fuel consumed (initial budget: 10,000,000,000 units); fee calculation is redefined accordingly.

New files:
- external/wasmtime/conanfile.py + conandata.yml — prebuilt C API binary package (macOS arm64, Linux x86_64; SHA256-pinned at v44.0.1)
- cmake/deps/Wasmtime.cmake — find_package(wasmtime REQUIRED)
- src/.../WasmtimeEngine.h/.cpp — IWasmEngine implementation

Build system changes:
- CMakeLists.txt, conanfile.py: with_wasmtime option (default on)
- cmake/RippledCore.cmake: link wasmtime::wasmtime alongside wasmedge::wasmedge

Protocol changes:
- features.macro: XRPL_FEATURE(WasmtimeEngine, Supported::yes, DefaultNo)
- WasmEngine.h: constexpr kWasmtimeInitialFuel = 10'000'000'000ULL (consensus-fixed)
- applyHook.cpp, SetHook.cpp, Change.cpp: engine selected by featureWasmtimeEngine

Implementation notes:
- Consensus-fixed config: consume_fuel=true, wasm_simd=true, relaxed_simd=false, reference_types=true, bulk_memory=true,  multi_value=false, nan_canonicalization=true
- Termination ABI: accept/rollback sets ExecState::terminated flag then returns a wasm_trap_t* to unwind the guest; execute() checks the flag before inspecting callErr to distinguish clean termination from errors
- Memory access workaround (ensureMemoryExported): Wasmtime lacks an index-based memory accessor equivalent to WasmEdge_CallingFrameGetMemoryInstance. The binary is patched before instantiation to inject a "memory" export when the module owns memory without exporting it, enabling wasmtime_caller_export_get() inside host callbacks.
2026-05-08 16:49:10 +09:00
..
2026-02-20 07:11:13 +09:00
2026-02-20 08:05:47 +09:00
2026-02-20 07:11:13 +09:00
2026-02-20 07:11:12 +09:00
2026-02-20 07:26:21 +09:00
2026-02-20 07:11:14 +09:00
2026-02-20 07:11:13 +09:00
2026-04-28 18:23:31 +10:00
2026-02-20 08:05:47 +09:00
2026-02-20 07:11:13 +09:00
2026-02-20 08:09:45 +09:00
2026-02-20 07:11:13 +09:00
2026-02-20 07:11:12 +09:00
2026-02-20 07:11:13 +09:00
2026-02-20 07:11:13 +09:00
2026-02-20 08:05:47 +09:00
2026-02-20 08:05:50 +09:00
2026-02-20 07:11:13 +09:00
2026-02-20 07:11:13 +09:00
2026-02-20 07:11:13 +09:00
2026-02-20 07:11:13 +09:00
2026-02-20 07:11:13 +09:00
2026-02-20 07:11:13 +09:00
2026-02-20 08:02:59 +09:00
2026-02-20 07:11:12 +09:00
2026-02-20 07:11:13 +09:00
2026-02-20 07:11:13 +09:00
2026-04-28 18:23:31 +10:00
2026-02-20 07:11:13 +09:00
2026-02-20 07:11:13 +09:00
2026-02-20 07:11:12 +09:00
2026-02-20 07:11:13 +09:00
2026-02-20 08:05:47 +09:00
2026-02-20 07:11:13 +09:00
2026-02-20 08:05:47 +09:00
2026-02-20 07:11:13 +09:00
2026-02-20 07:26:21 +09:00
2026-02-20 08:02:59 +09:00
2026-02-20 07:11:13 +09:00
2026-02-20 07:11:13 +09:00
2026-02-20 08:05:47 +09:00
2026-02-20 07:11:13 +09:00
2026-02-20 07:11:13 +09:00
2026-02-20 07:11:13 +09:00
2026-02-20 07:11:13 +09:00
2026-02-20 07:11:13 +09:00

protocol

Classes and functions for handling data and values associated with the XRP Ledger protocol.

Serialized Objects

Objects transmitted over the network must be serialized into a canonical format. The prefix "ST" refers to classes that deal with the serialized format.

The term "Tx" or "tx" is an abbreviation for "Transaction", a commonly occurring object type.

Optional Fields

Our serialized fields have some "type magic" to make optional fields easier to read:

  • The operation x[sfFoo] means "return the value of 'Foo' if it exists, or the default value if it doesn't."
  • The operation x[~sfFoo] means "return the value of 'Foo' if it exists, or nothing if it doesn't." This usage of the tilde/bitwise NOT operator is not standard outside of the rippled codebase.
    • As a consequence of this, x[~sfFoo] = y[~sfFoo] assigns the value of Foo from y to x, including omitting Foo from x if it doesn't exist in y.

Typically, for things that are guaranteed to exist, you use x[sfFoo] and avoid having to deal with a container that may or may not hold a value. For things not guaranteed to exist, you use x[~sfFoo] because you want such a container. It avoids having to look something up twice, once just to see if it exists and a second time to get/set its value. (Real example)

The source of this "type magic" is in SField.h.