Shunkichi Sato

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

Here are my comments at the moment, though I'm still exploring major public chains: - We need a mechanism to ensure that what is validated during pre-execution remains valid long...

> - They have 2 _certain business operations_ performed by the clients (i.e. accounts registered by the admin account): > 1. "Instant Money Transfers" > 2. "Flexible Withdrawals" The CBDC...

Imo, the key differences lie in UX and how each addresses the halting problem: - Solana: The transaction either succeeds by taking the entire user-specified fee, or fails if the...

> ### [Fee deduction and refund logic](https://soramitsu.atlassian.net/wiki/spaces/IS/pages/5238128641/Fee+Proposal+for+Instruction+Transaction+Processing#Fee-deduction-and-refund-logic) To ensure the logic is MECE, we can define the decision flow as follows, for example: ```mermaid flowchart TD S((Start)) A{Is the account...

Updated the decision flow to reflect permission validation and the execution-and-deduction cycle

@aoyako - Unless the user specifies a fuel limit, the system must impose one during pre-execution. If the limit is too high, it permits resource waste; if it is too...

I’ve taken the liberty of converting this to a draft for the time being.

> https://github.com/hyperledger-iroha/iroha/issues/5230#issuecomment-2627825639 This error seems to be different from the one originally reported. Are you still experiencing both errors, or has one been partially resolved? Just to let you know,...

> Q: What if this peer is malicious? I think this cannot be a drawback of the solution, even if the malicious peer is the only one who could gossip...