Shunkichi Sato
Shunkichi Sato
Also, just to clarify, I'm still asking about requirements, not proposing solutions
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...
> 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...
> 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,...
> separate accountability for fee payments and transfers This has actually turned out to be a requirement, which would mean fees should be included in transaction payloads. Possible approaches from...
Haven't `SetTransaction::decrease_repeats` and `remove_zeros` already achieved this?
If we could specify a range instead of a count from an offset, we could fetch even a single block. Could the chain ID be useful in some way for...
I was simply suggesting an alternative expression of the query -- `height_range=(1,1)` instead of `offset=1499; limit=1` -- and I won't insist on it. Yeah, it makes sense to identify the...
https://github.com/hyperledger-iroha/iroha/pull/5015#issuecomment-3050490455
After #4225 and #4555, the only advantage I can think of for working on this ("genesis state", essentially same as #4409) is to remove a branch of whether it is...