Research transaction fees

[takemiyamakoto]

I think we can use triggers for this (e.g., post-execute triggers).

[e-ivkov]

In the Trigger RFC we discussed why using triggers for transaction fees might be difficult. And decided to keep it either as a WASM Plugin or just highly configurable at runtime system.

[s8sato]

Requirements for the transaction fees I understand at the moment:

• Fees should be determined before execution
• Introduce Instruction Weights #1214 as atomic weights that will be summed to an executable weight
• Estimate complexity of wasm executables. How are other blockchains using wasm as a smartcontract language calculating fees?
• Define a rate between the weight and the "base currency" in the chain

Do you have any updates about this @takemiyamakoto ?

[mversic]

some additional resoures

https://soramitsu.atlassian.net/wiki/spaces/~61e107308534980073335d24/pages/5080711170/Iroha+2+MVP+Fees+structure+for+CBDC

https://build.avax.network/docs/api-reference/guides/txn-fees

[s8sato]

Gas consumption is measured across four dimensions:

1. Bandwidth The transaction size in bytes.
2. Reads The number of state/database reads.
3. Writes The number of state/database writes.
4. Compute The compute time in microseconds.

The total gas consumed ($G$) by a transaction is:

$$G=B+1000R+1000W+4C$$

This provides useful insights. To estimate each dimension:

• Bandwidth: The client can calculate the transaction size by itself.
• Compute: The only way I can think of right now is statistical prediction based on other dimensions.
• Reads and Writes: I have the following idea:

Currently, user logic can contain queries and instructions in any arrangement. As an alternative, we could require that queries be placed at the beginning and instructions at the end:

fn read_request() -> ReadRequest; // static
fn write_request(input: ReadResult) -> WriteRequest; // dynamic, return value depends on the state

Note that these functions do not execute queries or instructions directly; they merely return requests to the host.

Write requests are state-dependent but should be within a predictable range. We can allow the logic author to declare the maximum possible set of write requests:

impl From<WriteRequest> for WriteRequestAbstract {}
impl PartialOrd for WriteRequestAbstract {}
fn write_union() -> WriteRequestAbstract; // static

The host would then validate the condition actual_write_request <= expected_write_union at runtime.

[s8sato]

Regarding wasm executables, fees could simply be proportional to the maximum allowed complexity -- the fuel parameter. What do you think?

[0x009922]

Regarding wasm executables, fees could simply be proportional to the maximum allowed complexity -- the fuel parameter. What do you think?

@s8sato it is simple, but might be excessively large for very simple smartcontracts.

I have an idea:

• Compute fee based on space transaction occupies (includes metadata, instructions count, wasm blob size) and, if it is Executable::Wasm, also base fee on the fuel spent on the WASM
• Transaction authority must specify how much fuel they are ready to spend. Executor than could check before WASM execution that the account actually has enough to pay that maximum price. Then Iroha executes WASM and tells to executor how much fuel it took. Then executor deducts actual fee from the account.
• Should be there something different for triggers? They are also just triggering Executable, and same rules apply (not sure about the space occupation in this case).

Pros:

• Takes into account both space and time complexity into fee calculation
• No need to think about "precomputing" fees

Concerns:

• Executable::Instructions and Executable::Wasm are very different by nature. I expect it to be nearly impossible to balance "fair" fee calculation for them. Probably, we will end up with a situation that it is either always less expensive to use instructions, or always less expensive to use WASM-based approach. Is it okay?
• We store both successful and failing transactions in the blockchain. Failing transactions still take both space and compute. The only difference is that their effect is not committed.
• Making queries might be also very complex, and it is done outside of the WASM. Therefore, it is not included in the fuel WASM takes.

[mversic]

• Compute fee based on space transaction occupies (includes metadata, instructions count, wasm blob size) and, if it is Executable::Wasm, also base fee on the fuel spent on the WASM

In the case of wasm it should sum up both fuel and the price for every instruction because wasm ends up calling ISI on the wsv as do non-wasm transactions

[mversic]

Compute fee based on space transaction occupies (includes metadata, instructions count, wasm blob size) and, if it is Executable::Wasm, also base fee on the fuel spent on the WASM

this sounds to me as if you're proposing to have 2 different types of fees, i.e. space fee and compute fee. While we can have space fee I think that we must have a compute fee for every ISI. Then the compute fee of a wasm is the sum of every ISI compute fee it executes and it's own fuel consumption