Add technical account that will receive network fees

[mversic]

This account should be given as part of the configuration. Fees don't need to be elastic. Fixed fees are ok

[s8sato]

Let me confirm the requirements:

• This issue concerns the network fee, which is part of the transaction fee but not the entire transaction fee, correct?
• Should the network fee be fixed? If so, no calculations would be required
• Is the technical account expected to be replaced after deployment?

If there are any key takeaways from private discussions, please share them for the reviewers

[aoyako]

• Is the technical account expected to be replaced after deployment?

I doubt technical account and fee options will be frequently changed after deployment. In the initial implementation, an upgrade to a new executor should do the job. In the future, it would be good to have advanced functionality to change technical account and fee calculation options (fixed, dynamic).

[aoyako]

As @mversic pointed out, the fees processing logic can be implemented in the custom executor. It would allow to separate the fees-related features from the core iroha. Since it would be an "upgrade", peers won't need to update the iroha version. Moreover, the future logic for fees correction, such as adding new fee calculation rules, would be seamless.

[s8sato]

Allowing the executor to modify fee calculation would mean that fee payments are mixed into and implied within instructions. Is that acceptable?

Regarding modularity, what were the reasons for rejecting trigger-based approaches?

[s8sato]

Also, just to clarify, I'm still asking about requirements, not proposing solutions

[s8sato]

We've identified some drawbacks to trigger-based approaches, even if any viable ones exist:

• Triggers are processed post-execution, which can result in uncollected fees due to insufficient balances.
• Trigger executions introduce performance overhead.

My initial concern regarding modifying instruction behavior through an executor was how to maintain separate accountability for fee payments and transfers.
Simply adding transaction metadata indicating the fee amount may be sufficient

[s8sato]

Simply adding transaction metadata indicating the fee amount may be sufficient

This approach doesn't seem viable at all because:

• The executor can interpret instructions differently but cannot modify transaction payloads.
• If it could modify them, it would break transaction signatures by reversing the lifecycle.

So fees cannot be recorded in (external) transactions themselves.
Instead, the fee records, along with their corresponding transactions, might be stored in the state and queried.
However, if fees are not recorded as internal transactions, the transaction history will not accurately reflect asset balances

[mversic]

However, if fees are not recorded as internal transactions, the transaction history will not accurately reflect asset balances

Very good point. This is part of a larger problem that executor instructions are not transactional (neither are triggers' as was noted here #4968 ) and not specific to network fees

[s8sato]

So fees cannot be recorded in (external) transactions themselves.

Alternatively, a peer could return a certificate about the fee to the client, prompting it to reconstruct the transaction.

However, all of the above assumes that separate accountability is a requirement. Does this matter in the first place?

[aoyako]

Can we have a new set of instructions that wrap the default ones, but with fee calculation enabled (and block user calls to default isi)? Metadata field could be added there so users would be able to specify the fee amounts if they need. This approach would keep the same logic behind default instructions and leave a trace. However, this approach doesn't help to track smartcontracts fee refunding.