Shunkichi Sato

Currently, our coverage is failing to ignore certain paths: [The coverage generating command](https://github.com/hyperledger/iroha/blob/b9f28442bf4225f1647901629a4baed3b122cc3c/.github/workflows/iroha2-dev-pr.yml#L63) expects `client_cli` should be ignored, while [sonar](https://sonar.soramitsu.co.jp/component_measures?id=hyperledger%3Airoha&metric=uncovered_lines&selected=hyperledger%3Airoha%3Aclient_cli) (you may need to request access to DevOps) detects 753...

- What identity the signatory of "omnibus account" will correspond to? Is it a chunk of domestic accounts? - Does it intend a clearing over domestic accounts to reduce transaction...

Speaking of preventing orphaned triggers, I guess trigger will be able to be identified as an account. This can be applied to cases where the registrant is not necessarily superior...

- It would be enough to sign `payload.header` if it derives `payload.commit_topology` and `payload.event_recommendations` - During the inclusion verification, the light client would test the other node to see if...

Ah, I guess what you see as a problem is [`HashOf` implementation](https://github.com/hyperledger/iroha/blob/fad3e0c45fab4946af2c59e8b05e45051cfb2259/data_model/src/block.rs#L153-L156). If so, yeah, this would be a problem when that approach is required since light clients would store...

It sounds natural to me that a block hash is transient until it become `CommittedBlock`. It would not matter unless hash is used as an identifier

If the problem is that a block hash is affected by the aggregating signatures, wouldn't it be enough to change the logging implementation to refer to `hash_of_payload`?

One of the possible paths is as follows: 1. as of f12077d35 ```rust struct AccountId { domain_id: DomainId, signatory: PublicKey, } ``` 2. shallow objects #3921 should allow `AccountId` to...

As I understand it, according to @mversic your suggestion, the process when an account is targeted is as follows: - public use - the target is immediately registered no matter...

The feature might require the separate and relational entities after all. As I understand it, an example where a new account "carol" comes to exercise its authority in public use...