Marin Veršić

Representation of key pair in configuration files

4

It has been [mentioned](https://github.com/hyperledger/iroha/pull/2130#discussion_r855210627) recently that in `client::Configuration`/`cli::Configuration`/`genesis::Configuration` we store `public_key` and `private_key` as separate variables as in: ```rs pub struct Configuration { pub public_key: PublicKey, pub private_key: PrivateKey, }...

we need to provide ability to alter roles for external users. They need to be able to add/remove permissions from a role

[suggestion] Make Permissions an entity that references accounts

1

I'm suggesting here to swap the relation. We shouldn't have accounts hold permissions/roles, rather permissions/roles should hold accounts

I understand that this and other todos around what used to be the `wasm` crate hail from the expression validator PR, but I didn't see any issues created for it...

Domain logo should be stored as a metadata value

## Description ### Linked issue Closes #4393 ### Benefits ### Checklist - [ ] I've read `CONTRIBUTING.md` - [ ] I've used the standard signed-off commit format (or will squash...

dynamic parameter value

13

1. I think that we might want to split `***Limits` into it's constituents 2. I think that having `Numeric` is sufficient because values should be loosely typed and checked in...

Rename `iroha_client_cli` into `iroha`

4

It makes much more sense for the end user to just call `iroha` when interacting with cli, wouldn't you agree?

Rename `Upgrade::new` into `Upgrade::executor`

1

`Upgrade::new` is very vague. Either rename it into `Upgrade::executor` or `UpgradeExecutor::new`. The assumption here is that there will be other things to upgrade, not only executor. Is this correct?