Client Configuration
Let's look at the client configuration options.
Client configuration example
{
"PUBLIC_KEY": "ed01207233BFC89DCBD68C19FDE6CE6158225298EC1131B6A130D1AEB454C1AB5183C0",
"PRIVATE_KEY": {
"digest_function": "ed25519",
"payload": "9ac47abf59b356e0bd7dcbbbb4dec080e302156a48ca907e47cb6aea1d32719e7233bfc89dcbd68c19fde6ce6158225298ec1131b6a130d1aeb454c1ab5183c0"
},
"ACCOUNT_ID": "alice@wonderland",
"BASIC_AUTH": {
"web_login": "mad_hatter",
"password": "ilovetea"
},
"TORII_API_URL": "http://127.0.0.1:8080/",
"TORII_TELEMETRY_URL": "http://127.0.0.1:8180/",
"TRANSACTION_TIME_TO_LIVE_MS": 100000,
"TRANSACTION_STATUS_TIMEOUT_MS": 15000,
"TRANSACTION_LIMITS": {
"max_instruction_number": 4096,
"max_wasm_size_bytes": 4194304
},
"ADD_TRANSACTION_NONCE": false
}
Generation
You can use kagami
to generate the default client configuration:
$ kagami config client > client-config.json
Public and Private Keys
The configs/client_cli/config.json
client configuration file should contain a pair of the user's public PUBLIC_KEY
and private PRIVATE_KEY
cryptographic keys for their account's ACCOUNT_ID
.
For details on cryptographic keys, see Public Key Cryptography.
User account
The ACCOUNT_ID
should be self-explanatory. The only thing you need to worry about is that the account must already exist in the blockchain. In other words, the account you provide here should already be registered.
Note
Iroha is case-sensitive, meaning that Alice@wonderland is different from alice@wonderland. It should go without saying that alice@wonderland is not the same as alice@looking_glass either, since these accounts belong to different domains, wonderland
and looking_glass
.
Basic Authentication Credentials
The idea of basic authentication credentials is to provide the access control using a web server with a reverse proxy like Nginx while these credentials are ignored by the Iroha peers.
The login and password will be filled by the client and used for the Authorization
HTTP header.
Use this style of configuration to provide the basic authentication credentials (login and password):
"BASIC_AUTH": {
"web_login": "mad_hatter",
"password": "ilovetea"
},
Iroha Public Addresses
TORII
is the module in charge of handling incoming and outgoing connections. For client configuration, you can set up two addresses: TORII_API_URL
and TORII_TELEMETRY_URL
.
TORII_API_URL
First, the TORII_API_URL
is the same as TORII
API_URL
in the peer configuration. This is the module responsible for handling incoming and outgoing connections. You should also add the prefix http://
or (preferably) https://
to the address. For example:
"TORII_API_URL": "http://127.0.0.1:8080"
TORII_TELEMETRY_URL
The TORII_TELEMETRY_URL
is used to specify the prometheus endpoint address. You can set TORII_TELEMETRY_URL
like this:
"TORII_TELEMETRY_URL": "http://127.0.0.1:8180"
A GET
request to the 127.0.0.1:8180/status
will give you a JSON-encoded representation of the top-level metrics, while a GET
request to 127.0.0.1:8180/metrics
will give you a (somewhat verbose) list of all available metrics gathered in Iroha. You might want to change this if you're having trouble gathering metrics using prometheus
.
INFO
Learn how to monitor Iroha performance using prometheus.
Transaction Limits
You can specify the transaction limits that each transaction must adhere to: the maximum number of instructions and the maximum size of a WASM blob (in bytes). For example:
{
"max_instruction_number": 4096,
"max_wasm_size_bytes": 4194304
}
Transaction TTL and Timeout
Configure the time-to-live (TTL) for transactions and the timeout to wait for the status. Both values have to be provided in milliseconds. For example:
"TRANSACTION_TIME_TO_LIVE_MS": 100000,
"TRANSACTION_STATUS_TIMEOUT_MS": 15000,
Transaction Nonce
If you set ADD_TRANSACTION_NONCE
to true
, Iroha will create different hashes for transactions that occur repeatedly and simultaneously.