Unclear messages appear during reading transactions

Version Info:
indy-node=1.2.209

Steps to Reproduce:
1. Set up the docker pool of 4 nodes with 1.2.209 version of indy-node.
2. Install client with the same version (using other machine, not docker container created by client_for_pool_start.sh).
3. Copy content of /var/lib/indy/sandbox/pool_transactions_genesis and /var/lib/indy/sandbox/domain_transactions_genesis files from node machine to /.indy-cli/networks/sandbox/pool_transactions_genesis and /.indy-cli/networks/sandbox/domain_transactions_genesis on client machine.
4. Run the client. Verify that all works correctly by rending write and read transactions.
=> transactions are successfully written and read.
5. Stop services on n-1 nodes one-by-one and send read transaction after each node stopping.

Actual Results:
Here is output of CLI for described steps:

indy@sandbox> send NYM dest=V4SGRU86Z58d6TV7PBUe61 role=TRUST_ANCHOR verkey=~V4SGRU86Z58d6TV7PBUe61
Adding nym V4SGRU86Z58d6TV7PBUe61
Nym V4SGRU86Z58d6TV7PBUe61 added
indy@sandbox> send GET_NYM dest=V4SGRU86Z58d6TV7PBUe61
Getting nym V4SGRU86Z58d6TV7PBUe61
Current verkey for NYM V4SGRU86Z58d6TV7PBUe61 is ~V4SGRU86Z58d6TV7PBUe61 with role TRUST_ANCHOR
CONNECTION: HoN6XaczjWJpnyZUB1LvtpKpVLmzjJv78rCY3scKGt99 disconnected from Node5C
indy@sandbox> send NYM dest=V4SGRU86Z58d6TV7PBUe62 role=TRUST_ANCHOR verkey=~V4SGRU86Z58d6TV7PBUe62
Adding nym V4SGRU86Z58d6TV7PBUe62
Nym V4SGRU86Z58d6TV7PBUe62 added
indy@sandbox> send GET_NYM dest=V4SGRU86Z58d6TV7PBUe62
Getting nym V4SGRU86Z58d6TV7PBUe62
Current verkey for NYM V4SGRU86Z58d6TV7PBUe62 is ~V4SGRU86Z58d6TV7PBUe62 with role TRUST_ANCHOR
CONNECTION: HoN6XaczjWJpnyZUB1LvtpKpVLmzjJv78rCY3scKGt99 disconnected from Node4C
indy@sandbox> send NYM dest=V4SGRU86Z58d6TV7PBUe63 role=TRUST_ANCHOR verkey=~V4SGRU86Z58d6TV7PBUe62
Adding nym V4SGRU86Z58d6TV7PBUe63
indy@sandbox> send GET_NYM dest=V4SGRU86Z58d6TV7PBUe62
Getting nym V4SGRU86Z58d6TV7PBUe62
b"\x86\xbb\xfa\xafdun\x90\xe3k\xd7T&@'\x11)\x9c\x9bt\xe3\xceh\x90\x95\x97\xaeB\x04\xf9I\x93"
b"\x86\xbb\xfa\xafdun\x90\xe3k\xd7T&@'\x11)\x9c\x9bt\xe3\xceh\x90\x95\x97\xaeB\x04\xf9I\x93"
b"\x86\xbb\xfa\xafdun\x90\xe3k\xd7T&@'\x11)\x9c\x9bt\xe3\xceh\x90\x95\x97\xaeB\x04\xf9I\x93"
Current verkey for NYM V4SGRU86Z58d6TV7PBUe62 is ~V4SGRU86Z58d6TV7PBUe62 with role TRUST_ANCHOR
b"\x86\xbb\xfa\xafdun\x90\xe3k\xd7T&@'\x11)\x9c\x9bt\xe3\xceh\x90\x95\x97\xaeB\x04\xf9I\x93"
CONNECTION: HoN6XaczjWJpnyZUB1LvtpKpVLmzjJv78rCY3scKGt99 disconnected from Node3C
indy@sandbox> send GET_NYM dest=V4SGRU86Z58d6TV7PBUe61
Getting nym V4SGRU86Z58d6TV7PBUe61
b"\x86\xbb\xfa\xafdun\x90\xe3k\xd7T&@'\x11)\x9c\x9bt\xe3\xceh\x90\x95\x97\xaeB\x04\xf9I\x93"
b"\x86\xbb\xfa\xafdun\x90\xe3k\xd7T&@'\x11)\x9c\x9bt\xe3\xceh\x90\x95\x97\xaeB\x04\xf9I\x93"
b"\x86\xbb\xfa\xafdun\x90\xe3k\xd7T&@'\x11)\x9c\x9bt\xe3\xceh\x90\x95\x97\xaeB\x04\xf9I\x93"
Current verkey for NYM V4SGRU86Z58d6TV7PBUe61 is ~V4SGRU86Z58d6TV7PBUe61 with role TRUST_ANCHOR
indy@sandbox> send GET_NYM dest=V4SGRU86Z58d6TV7PBUe62
Getting nym V4SGRU86Z58d6TV7PBUe62
b"\x86\xbb\xfa\xafdun\x90\xe3k\xd7T&@'\x11)\x9c\x9bt\xe3\xceh\x90\x95\x97\xaeB\x04\xf9I\x93"
b"\x86\xbb\xfa\xafdun\x90\xe3k\xd7T&@'\x11)\x9c\x9bt\xe3\xceh\x90\x95\x97\xaeB\x04\xf9I\x93"
b"\x86\xbb\xfa\xafdun\x90\xe3k\xd7T&@'\x11)\x9c\x9bt\xe3\xceh\x90\x95\x97\xaeB\x04\xf9I\x93"
Current verkey for NYM V4SGRU86Z58d6TV7PBUe62 is ~V4SGRU86Z58d6TV7PBUe62 with role TRUST_ANCHOR
CONNECTION: HoN6XaczjWJpnyZUB1LvtpKpVLmzjJv78rCY3scKGt99 disconnected from Node2C
indy@sandbox> send GET_NYM dest=V4SGRU86Z58d6TV7PBUe62
Getting nym V4SGRU86Z58d6TV7PBUe62
b"\x86\xbb\xfa\xafdun\x90\xe3k\xd7T&@'\x11)\x9c\x9bt\xe3\xceh\x90\x95\x97\xaeB\x04\xf9I\x93"
b"\x86\xbb\xfa\xafdun\x90\xe3k\xd7T&@'\x11)\x9c\x9bt\xe3\xceh\x90\x95\x97\xaeB\x04\xf9I\x93"
b"\x86\xbb\xfa\xafdun\x90\xe3k\xd7T&@'\x11)\x9c\x9bt\xe3\xceh\x90\x95\x97\xaeB\x04\xf9I\x93"
b"\x86\xbb\xfa\xafdun\x90\xe3k\xd7T&@'\x11)\x9c\x9bt\xe3\xceh\x90\x95\x97\xaeB\x04\xf9I\x93"
b"\x86\xbb\xfa\xafdun\x90\xe3k\xd7T&@'\x11)\x9c\x9bt\xe3\xceh\x90\x95\x97\xaeB\x04\xf9I\x93"
b"\x86\xbb\xfa\xafdun\x90\xe3k\xd7T&@'\x11)\x9c\x9bt\xe3\xceh\x90\x95\x97\xaeB\x04\xf9I\x93"
b"\x86\xbb\xfa\xafdun\x90\xe3k\xd7T&@'\x11)\x9c\x9bt\xe3\xceh\x90\x95\x97\xaeB\x04\xf9I\x93"
b"\x86\xbb\xfa\xafdun\x90\xe3k\xd7T&@'\x11)\x9c\x9bt\xe3\xceh\x90\x95\x97\xaeB\x04\xf9I\x93"
b"\x86\xbb\xfa\xafdun\x90\xe3k\xd7T&@'\x11)\x9c\x9bt\xe3\xceh\x90\x95\x97\xaeB\x04\xf9I\x93"
b"\x86\xbb\xfa\xafdun\x90\xe3k\xd7T&@'\x11)\x9c\x9bt\xe3\xceh\x90\x95\x97\xaeB\x04\xf9I\x93"
b"\x86\xbb\xfa\xafdun\x90\xe3k\xd7T&@'\x11)\x9c\x9bt\xe3\xceh\x90\x95\x97\xaeB\x04\xf9I\x93"

Expected Results:
Obvious problem is that messages are strange and useless. Messages should not be shown or they should be informative for user.

Question:
Is that correct that pool_transactions_genesis and domain_transactions_genesis are not enough for correct validation of blskeys on CLI side?

Additional Information:
If you will use docker client (created by client_for_pool_start.sh), client will work correctly, error messages will not be shown.
Genesis files of docker client and client on separated machine were double-checked and they are the same.