Modularize Executor: split Fee Calculator and Authorizer

[s8sato]

Last updated: Jun 02, 2025

Proof of Concept

Proposal

The current executor has grown into a monolithic component, exhibiting characteristics of the God Object anti-pattern by taking on too many unrelated responsibilities. Specifically, it currently handles:

• Instruction interpretation
• Permission token definitions
• Permission validation logic

These concerns should be modularized to improve maintainability, clarity, and extensibility.

Adding new responsibilities, such as fee calculation, would further entangle its role.

While it may seem logical for the executor to serve as a fee calculator—given that it already controls all execution paths and exists as an external module—this coupling would only intensify architectural complexity.

Proposed Refactor

Fee Calculator

A standalone module responsible solely for computing fees based on requests and context provided by the host.

Executor

Currently holds a &mut StateTransaction within wasmtime::Store, enabling arbitrary instruction and query execution. This grants it excessive power and makes it a bloated interface with the host.

Reduce the executor to a minimal core: limit its role to verifying permission tokens against read/write requests and isolating it from broader execution logic.

Enabling Modularity

Planned improvements:

• Registrable Wasm Instructions delegate instruction customization to the host: #5147
• Registrable Permissions shift permission token definitions to the host as well: #5359

The executor will be reduced to a pure permission validator—or, more succinctly, an authorizer—that accepts read/write requests paired with permission tokens and returns verdicts to the host.

In this reduced form, the wasmtime::Store would only need to maintain minimal context, such as the current block header.

Benefits of Modularity

By making both the fee calculator and the authorizer optional modules, we enable flexible chain configurations:

• A permissioned chain can omit the fee module.
• A permissionless chain can omit the authorizer.

This modular architecture enhances clarity, maintainability, and adaptability across diverse deployment environments.

Previous description

According to what #5358 is planning, the current responsibilities of the executor can be broken down into:

• Permission Definer ... Can be delegated to #5359
• Permission Validator ... Can be considered a user-defined function that:
  • Takes write requests or read results, permissions, and additional contextual information
  • Returns a boolean-like verdict
• Instruction Definer ... Can be delegated to https://github.com/hyperledger-iroha/iroha/issues/5147#issuecomment-2727613992
• Instruction Commander ... Can be removed, with its only responsibility being to return the verdict to the host.
• Query Definer ... Can be delegated to registrable custom queries.
• Query Commander ... Can be removed, with its only responsibility being to return the verdict to the host.

Suggestion

The executor should return the role of definer and commander to the core and regress to a pure permission validator. I suggest renaming it to Authorizer