Iroha 2

Appearance

Client Configuration ​

Let's look at the client configuration options.

Client configuration example
json
{
  "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
}
{
  "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:

bash
$ kagami config client > client-config.json
$ kagami config client > client-config.json

Public and Private Keys ​

Client configuration files should contain the pair of public (PUBLIC_KEY) and private (PRIVATE_KEY) keys for the user account (ACCOUNT_ID).

Refer to the chapter on public key cryptography for more details:

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):

json
"BASIC_AUTH": {
    "web_login": "mad_hatter",
    "password": "ilovetea"
  },
"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:

json
"TORII_API_URL": "http://127.0.0.1:8080"
"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:

json
"TORII_TELEMETRY_URL": "http://127.0.0.1:8180"
"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:

json
{
  "max_instruction_number": 4096,
  "max_wasm_size_bytes": 4194304
}
{
  "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:

json
"TRANSACTION_TIME_TO_LIVE_MS": 100000,
"TRANSACTION_STATUS_TIMEOUT_MS": 15000,
"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.