Page Comparison

• The administrator has configured environment for running Iroha executables
• The administrator has prepared the genesis block

Use case flow

1. The administrator launches the command to run Iroha peer and providing the path to the genesis block description
2. The Iroha peer read and validates the genesis block configuration
3. The Iroha peer starts the Iroha network according to the configuration in the genesis block
4. The Iroha peer provides "successfully started" report to the administrator

• The Iroha network is running
• The administrator has access to the root account of the network

• On At step 2, in case of the invalid genesis block, the Iroha peer shows corresponding error messages to the administrator and halts the network creation process

• The user has an account in the Iroha network
• The user has prepared the command
• The user has permissions to execute the instruction
• The Iroha network is working in normal condition

Use case flow

1. The user sends the instruction to the Iroha peer through the API
2. The Iroha peer receives the instruction and validates its contents
3. The Iroha peer checks that the user's account have enough permissions to run the instruction
4. The Iroha peer executes the instruction by applying it to the current block
5. The Iroha peer returns the result of the operation to the user

• The instruction is successfully executed and applied to the network state

• On step 2, of the instruction has invalid structure, the Iroha peer returns an error message with description to the users and stops the flow
• On step 3, if the user's account does not have required permissions, the Iroha peer returns information about that error and stops the flow

• The user has permissions to execute requested instruction

Use case flow

1. The user prepares the instruction parameters according to his/her needs
2. The user sends the instruction into the Iroha peer (<<includes>> FR0100)
3. The user uses the same connection for obtaining the status of the instruction finalization
4. The Iroha peer sends updates about the instruction finalization status to the user
5. The user receives the "successfully finalized" status about the instruction

• The instruction is accepted and finalized in the block-storage
• The user did not spend additional resources for redundant network connections and requests

• At Step 4 if the instruction cannot pass the validation, the user would not get the "successfully finalized" status; instead, he/she will get the "invalid instruction" status.
• At Step 4 if the network is in "bad" condition, the user would get the "successfully finalized" status eventually, when the network will return in a "good" state.