refactor(wasm): make wasm execution part of Instruction #5465

aoyako · 2025-06-12T07:22:26Z

First part of #5147 (Draft)

This PR refactors the following:

Previously, in a transaction, a single wasm executable can be submitted instead of instructions. Here, WASM execution was transferred from the transaction level to the instruction level.

As a result:

Multiple WASM can be submitted in contrast to a single executable.
Custom executor can handle wasm-related call visit_execute_wasm_smartcontract.

Breaking changes:

Replace Executable::Wasm to Executable::Instruction ( WasmExecutable<WasmSmartContract>).
The errors related to the error in the WASM execution will be associated with Instruction in contrast to Transaction.
Genesis transaction accepts WASM.

Issues to be addressed:

Since WASM execution is now at the instruction level, the runtime (fuel) should be reused from the transaction (see smartcontract and trigger).
It is planned to be addressed in Unification of wasm fuel across runtimes #5494.

Signed-off-by: Lohachov Mykhailo <[email protected]>

crates/iroha/src/client.rs

s8sato · 2025-06-12T13:46:04Z

crates/iroha/src/client.rs

Since WASM execution is now at the instruction level, the runtime (fuel) should be reused from the transaction

Regardless of whether the Wasmtime instance is reused, the host can keep track of how much fuel has been consumed.

Created #5494 . Separated because this PR is too big already.

crates/iroha_data_model/src/isi.rs

s8sato · 2025-06-12T14:10:25Z

crates/iroha_core/src/tx.rs

+                        // TODO: Can we check the number of instructions in wasm? Because we do this check
+                        // when executing wasm where we deny wasm if number of instructions exceeds the limit.


Counting write accesses at the static-analysis stage in a highly flexible language like Wasm—leave aside a DSL—is not realistic. A runtime approach would be better.

s8sato · 2025-06-12T14:25:19Z

crates/iroha_core/src/tx.rs

+                        // TODO: Can we check the number of instructions in wasm? Because we do this check
+                        // when executing wasm where we deny wasm if number of instructions exceeds the limit.
+                        //
+                        // Should we allow infinite instructions in wasm? And deny only based on fuel and size


Write-access limits and fee-based deterrence provide effective baseline defenses, but there are still gaps:

Write-access limit loophole
An attacker can spread many write requests over multiple transactions.
Mitigation: Enforce epoch-level limits by capping the total requests per account.

Fee-based deterrence loophole
A resourceful attacker can exploit lightweight loops or simply pay high fees.
Mitigation: To be determined.

s8sato · 2025-06-12T15:17:06Z

crates/iroha_data_model/src/isi.rs

+        /// Execute [`WasmSmartContract`].
+        Smartcontract(WasmExecutable<WasmSmartContract>),
+        /// Execute [`TriggerModule`] .
+        Trigger(WasmExecutable<TriggerModule>),


Rather than distinguishing between instant binary build-and-run (smart contracts) and pre-registered module calls (triggers), I suggest splitting the workflow into two operations: register (build) and call (run).

Enhanced extensibility:
Smart contracts are execution units, while triggers are mapping from conditions to execution unis. By introducing four distinct commands—register execution unit, invoke execution unit, register condition, and register mapping—we maximize reusability. This approach even integrates custom instructions.

No adverse memory impact:
The register command only stores hashes of blobs in memory.

Preserved instant execution:
Bundling register and call in a single transaction provides immediate execution, and UI can seamlessly abstract the two-step process from users.

The interface was changed to include only the execution of the wasm binaries. It is possible to allow registering binaries and later calling them by hash. However, for the smartcontacts users already have the binaries, and for triggers, they need to provide an event, which is not realistic.

As mentioned above, it’s possible to provide a UX that executes the binary directly while internally splitting it into two stages—registration and invocation.
Also, since this change pertains to the executable, its concerns should be separable from triggers, and commit 89a2b59 has nearly achieved that.

If you still plan something that conflicts with the latest comment in the original issue, it should be documented in that issue, since it would overturn the assumptions of all higher-level issues.

s8sato · 2025-06-12T15:21:52Z

crates/iroha/src/client.rs

It would be desirable to have a test demonstrating that multiple Wasm instructions can be used within a single transaction like a method chain.

Signed-off-by: Lohachov Mykhailo <[email protected]>

s8sato · 2025-07-14T05:47:25Z

crates/iroha_data_model/src/isi.rs

+        Serialize,
+        IntoSchema,
+    )]
+    pub enum InstructionBoxHashed {


I don’t think such redundancy across the entire InstructionBox, including builtin instructions, is unavoidable. Wouldn’t it be enough to just add two variants, such as WasmRegister(blob) and WasmCall(hash)?

I imagine it this way. Internally, for a trigger to be called, it needs to have:

A binary or a hash of the binary

A triggering action

As I understand it, WasmCall(hash) implies the action is a "manual call." In that case, there's no real difference between WasmCall(hash) and the already existing CallTrigger(id).

It's not a problem to add WasmCall(hash) or WasmRegister(blob), but for a complete trigger representation, we must also include the Action, for example, WasmCall(hash) should become WasmCall(hash, action).

This would be acceptable if we add checks to discard user-submitted calls with non-manual call actions. That would significantly relax the internal representation. However, personally, I believe that if an interface allows something and later rejects it, then the interface is poorly designed, especially for strongly-typed languages.

Another concern is with the developer-facing interface. If InstructionBox is used in place of InstructionBoxHashed, there's no guarantee that binaries will always be hashed, and future developers may mistakenly add them directly. I dislike this duplication but don’t see a viable way to avoid it (e.g., with generics or nested enums).

It seems we’re not on the same page about a few points. Let me clarify.

An instruction itself doesn’t dictate whether it’s run manually or automatically. That’s determined by whether the instruction is included in a user’s transaction or in a trigger execution.

As mentioned, a trigger is basically a mapping from the condition part (2. A triggering action) to the execution part (1. A binary or a hash of the binary), or a pair of them. An instruction—being a pure building block of the execution part—has nothing to do with the condition part.

Since the World model doesn’t yet support registering condition and execution parts separately, I assume at least three new fields instead of triggers (see https://github.com/hyperledger-iroha/iroha/pull/5355/files#r2204613082). The existing Action structure, which no longer matches our reality, will then be dismantled.

An instruction—being a pure building block of the execution part—has nothing to do with the condition part.

More precisely, the Wasm execution component will accept the triggering event as an optional input.
However, the main point here is that the Wasm instructions can be registered regardless of who will invoke them or under what conditions.

crates/iroha/src/client.rs

s8sato · 2025-07-14T06:28:43Z

crates/iroha_data_model/src/isi.rs

+        /// Execute [`WasmSmartContract`].
+        Smartcontract(WasmExecutable<WasmSmartContract>),
+        /// Execute [`TriggerModule`] .
+        Trigger(WasmExecutable<TriggerModule>),


As mentioned above, it’s possible to provide a UX that executes the binary directly while internally splitting it into two stages—registration and invocation.
Also, since this change pertains to the executable, its concerns should be separable from triggers, and commit 89a2b59 has nearly achieved that.

If you still plan something that conflicts with the latest comment in the original issue, it should be documented in that issue, since it would overturn the assumptions of all higher-level issues.

s8sato · 2025-07-14T06:31:57Z

integration_tests/tests/smart_contract.rs

+        vec![
+            WasmExecutable::binary(load_sample_wasm("mint_rose_smartcontract")),
+            WasmExecutable::binary(load_sample_wasm("mint_rose_smartcontract")),
+            WasmExecutable::binary(load_sample_wasm("mint_rose_smartcontract")),
+        ],


To demonstrate the dependencies between instructions, for example, an asset relay via Transfer would be a preferable.

s8sato · 2025-07-14T06:36:25Z

integration_tests/tests/triggers/wasm.rs

+use mint_rose_trigger_data_model::MintRoseArgs;
+
+#[test]
+fn multiple_wasm_triggers_in_transaction() -> Result<()> {


There’s no need to add any guarantees about the by-call trigger. It will be removed.

This topic is closely related to #5475 (comment):

In my view, by-call triggers will disappear in the near future with the resolution of #5147 or its derived issues due to the inherent contradiction in their role. A trigger is essentially a mapping from internal conditions to the execution unit, and if a user invokes the execution unit directly, it’s simply another kind of instruction.

refactor: consolidate wasm execution

ee63df2

Signed-off-by: Lohachov Mykhailo <[email protected]>

aoyako requested review from s8sato, mversic, outoftardis, 0x009922, DCNick3 and dima74 as code owners June 12, 2025 07:22

github-actions bot added the api-changes Changes in the API for client libraries label Jun 12, 2025

aoyako marked this pull request as draft June 12, 2025 07:22

fix: fmt

a29452b

Signed-off-by: Lohachov Mykhailo <[email protected]>

aoyako changed the title ~~Refactor: make wasm execution part of Instruction~~ fefactor(wasm api): make wasm execution part of Instruction Jun 12, 2025

aoyako added the Enhancement New feature or request label Jun 12, 2025

aoyako changed the title ~~fefactor(wasm api): make wasm execution part of Instruction~~ refactor(wasm): make wasm execution part of Instruction Jun 12, 2025

s8sato self-assigned this Jun 12, 2025

s8sato reviewed Jun 12, 2025

View reviewed changes

aoyako added 4 commits June 19, 2025 18:19

fix: remove wasm trigger calls from isi

89a2b59

Signed-off-by: Lohachov Mykhailo <[email protected]>

Merge branch 'main' into single_wasm_execution

2e90b57

fix: fmt

585c062

Signed-off-by: Lohachov Mykhailo <[email protected]>

fix: add tests for multu-wasm execution

a7469fc

Signed-off-by: Lohachov Mykhailo <[email protected]>

aoyako mentioned this pull request Jul 10, 2025

Unification of wasm fuel across runtimes #5494

Open

aoyako added 3 commits July 12, 2025 12:20

Merge branch 'main' into single_wasm_execution

c73cfca

chore: clippy

d3494e7

Signed-off-by: Lohachov Mykhailo <[email protected]>

chore: clippy

9735657

Signed-off-by: Lohachov Mykhailo <[email protected]>

aoyako marked this pull request as ready for review July 12, 2025 10:24

s8sato reviewed Jul 14, 2025

View reviewed changes

		// TODO: Can we check the number of instructions in wasm? Because we do this check
		// when executing wasm where we deny wasm if number of instructions exceeds the limit.

refactor(wasm): make wasm execution part of Instruction #5465

Are you sure you want to change the base?

refactor(wasm): make wasm execution part of Instruction #5465

Conversation

aoyako commented Jun 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

s8sato Jul 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

aoyako commented Jun 12, 2025 •

edited

Loading

s8sato Jul 14, 2025 •

edited

Loading