Iroha 2 requirements

• List of preconditions which must be satisfied before the use case can be applied
• Each precondition should be defined as the point in the list

Use case flow

1. The enumerated list of actions, which describes the interaction between actors step by step
2. Each step should involve a single actor as an object of the action
3. Each step can involve one or more actors as a subject of the action
4. Each use case can involve other use cases as dependencies by include or extend relationships

• One or more results of successfully finished use case

• List of alternative flows that can happen with the use case.
• Each entry should have the link to the step of the main use case flow when the alternative can occur
  • If needed, each entry can contain sub-entries
• Each entry should describe the consequences of the alternative flow

• List of exceptions that can happen during the use case flow, which can prevent it to be successfully finished
• Each entry should have the link to the step of the main use case flow when the exception can occur
  • If needed, each entry can contain sub-entries
• Each entry should describe the consequences of the exception

• 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

• 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 Iroha network is running
• The administrator has access to the account with permissions of adding peers to the network

Use case flow

1. The administrator configures and starts the new peer
2. The administrator prepares the transaction with instruction to add the new peer
3. The administrator sends the prepared transaction to the existing Iroha peer (<<include>> FR0100)
4. The existing Iroha peer initiates connection with the new Iroha peer
5. The new Iroha peer synchronizes the block-storage with existing Iroha peers
6. The new Iroha peer start functioning as fully functional peer in the current Iroha network

• The new peer is added into the network

• On step 5, if the synchronization cannot be finished for some reason, the new Iroha peer cannot join the network; use case stops

Use case flow

Use case flow

• The user has an account in the Iroha network
• The user has prepared the transaction for sending; transactions can consist of several instructions
• The user has permissions to execute all instruction included in the transaction
• The Iroha network is working in normal condition

Use case flow

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

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

• On step 4, if the current user's account is multi-signature, the result of the transaction will be applied to the block-store only when the number of signatures will reach the current quorum value. In other cases, the Iroha peer will return "pending" status as a response on step 5.

• On step 2, one of the instructions has invalid structure, the Iroha peer returns an error message with description to the user and stops the flow
• On step 3, if the user's account does not have required permissions to execute one of the instructions, the Iroha peer returns information about that error and stops the flow
• On step 3, in case of a multi-signature transaction, if the instruction signed using the key pair, which was already used for signing that instruction, the Iroha peer will return "already signed" error status and stop the flow

• The user has permission to create other users

Use case flow

1. The user prepares information about the account that should be created, which includes name, domain, the public key and permissions list
2. The user prepares instruction to send to the Iroha network according to the prepared information
3. The user sends the transaction with the instruction to the Iroha peer (<<include>> FR0100)
4. The Iroha peer returns the result of the instruction execution to the user

• The new account in the Iroha network is created

• On step 3, if the account with the provided name or public key already exists in the network, the Iroha peer will return "already exists" error status; user case flow will stop.

• The user has access to the Iroha account with permissions to change permissions of the target account

Use case flow

1. The user prepares information about set of permissions, which should be enabled or disabled for the target account
2. The user prepares instruction to send to the Iroha network according to the prepared information
3. The user sends the transaction with the instruction to the Iroha peer (<<include>> FR0100)
4. The Iroha peer returns the result of the instruction execution to the user

• The permissions of the target account was changed correspondingly

• On step 4, if the user disables the permission which is not enables on the target account, the Iroha peer return "Permission is not enabled" error status; use case flow stops
• On step 4, if the user enables the permission which is already enabled on the target account, the Iroha peer return "Permission already enabled" error status; use case flow stops

• The user has access to his/her account in the Iroha network
• The user's account has permissions to provide grantable permissions

Use case flow

1. The user prepares the instruction to grant one or more permissions to another account
2. The user sends the transaction with the prepared instruction to the Iroha peer (<<includes>> FR0100)
3. The Iroha peer returns the result of the instruction to the user

• The permission was granted to another account

• On step 3, if the user does not have permission to grant permissions to other accounts, the Iroha peer will return "Not permitted" error status; use case flow stops

• The user has permissions to send complex instructions with DSL sequence inside
• The user has permissions to execute each instruction inside the list of DSL sequence

Use case flow

1. The user builds the DSL sequence for the complex instruction
2. The user prepares the complex instruction to send to the Iroha peer
3. The user sends the complex instruction to the Iroha peer (<<include>> FR0100)
4. The Iroha peer returns the results of complex instruction execution to the user

• The complex instruction was executed and applied to the Iroha network

• On step 4, of there is not enough permissions to execute whole DSL sequence, the Iroha peer will return "not enough permissions" error status; use case flow stops.

• 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 transaction with 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.

• The user have permission to create new MST accounts

Use case flow

1. The user prepares information about new account, including list of signatories and quorum of signatures
2. The user creates new account in the Iroha network (<<include>> FR0101)
3. The user receives result of new account creation from the Iroha peer

• The new MST account with defined list of signatories and quorum is created

• On step 3, if amount of signatories in the list is lower, than quorum, the Iroha peer returns "Not enough signatories" error; use case flow stops

Use case flow

• The user has permissions to change the list of signatories to the required account
• The user has key pair for adding/deleting a signatory to/from the selected account

Use case flow

1. The user prepares the instruction of adding/deleting signatories for sending
2. The user sends the transaction with the instruction to the Iroha peer (<<include>> FR0100)
3. The user receives the response from the Iroha peer

• List of signatories for the selected account was changed correspondingly

• On step 2, if the signatory with the current key pair exists in the list of signatories in the target account, the Iroha peer will return "already added" error status; use case flow stops.

• There is a multi-signature account in the Iroha network
• The user has access to the one or many key pairs for the multi-signature account
• The current amount of signatures to the multi-signature transaction is lower than a current quorum value

Use case flow

• Amount of signatures in the signed instruction increased by 1 signature
• Signed instruction disappears from the list of pending instructions for the current user's account

• The user has permissions to change the conditions for the target multi-signature account

Use case flow

1. The user requests the list of currently configured conditions for the target multi-signature account
2. The user prepared the instruction with the list of conditions to be added/removed
3. The user sends the transaction with the instruction to the Iroha peer (<<include>> FR0100)
4. The Iroha peer sends the response to the user

• The list of conditions for the target multi-signature account was changed correspondingly

• The user has permissions to change the conditions (or some other, to discuss) for the target multi-signature account

Use case flow

1. The user prepared the instruction with the map of public keys and weight correspondence (e.g. key1 → 50, i.e. key2 → 25, key3 → 25)
   and the target quorum (e.g. 50 so that it is needed either to sign upcoming transactions of the user with either key1 or both key2 and key3)
2. The user sends the transaction with the instruction to the Iroha peer (<<include>> FR0100)
3. The Iroha peer sends the response to the user

• The list of signatories weights and target quorum for the target multi-signature account was changed correspondingly

• Iroha 2 whitepaper
• Generic functionality of Iroha

• User has access to the account with permissions, which allows to get results of target query

Use case flow

• User receives the response with the requested data

• On step 2, if the query was formed not correctly (for example, because of problems with the client library) the Iroha peer returns error with result of validation, use case execution stops.
• On step 3, if the user's account does not have enough permissions, the Iroha peer returns error with corresponding status, use case execution stops.

Use case flow

Use case flow

• The user has permissions to request the list of pending transactions

Use case flow

• The user has the list of currently pending instructions

• On step 3, if there are no currently pending transactions, the Iroha peer will return "empty response" status

• The user has permissions to request a list of conditions to the target multi-signature account

Use case flow

1. The user prepares query for requesting a list of currently configured conditions of signing for the target multi-signature account
2. The user sends the query to the Iroha peer (<<include>> FR0200)
3. The user receives the list of currently configured conditions of signing for the target multi-signature account

• The user received the list of conditions for the target account

• On step 3, if there are no currently configured conditions, the Iroha peer will return "empty response" status
• On step 3, if the account is not multi-signature, the Iroha peer will return "not applicable" status

• The user has permissions to request the block by its number

Use case flow

• The user receives the requested block from the blockstore

• On step 3, if there are no block specified, the Iroha peer will return "error/no such block" response

• The user has permissions to request blocks (subscription, can be separate permission or from <<include>> FR0205)

Use case flow

• The user has got stable channel for continuous block obtaining, which can be used for getting all new blocks on the current peer until the connection will be interrupted

N/A

• The user has permissions to request the list of pending transactions (subscription, can be separate permission or from <<include>> FR0203)

Use case flow

• The user has got stable pending transactions perception channel and newly arriving pending transactions

• The user has permissions to get results of the target query

Use case flow

1. The user prepares request data for the target query
2. The user establishes permanent connection to the Iroha peer and sends the query
3. The Iroha peer confirms the connection and start sending updates on the query results until the user closes the connection
4. The user receives the results and performs continuous analysis of the payload

• The user has continuous results of query execution

• The user has permissions to get results of the target query

Use case flow

1. The user prepares request data for the target query
2. The user sends the query to the Iroha peer (<<include>> FR0200)
3. The Iroha peer returns response containing result of the query as well as the Merkle proof of its validity and relation to the current block-store
4. The user receives the response and validates the correctness of the data by checking Merkle proof and obtained data

• The user has result of the query request with merkle proof of its validity

Use case flow

<<extends>> FR0200, substitutes step 4:

1. The Iroha peer collects data from the block storage at the moment, requested in the query

• The user received the requested information about the information in block store on the provided date

• The user has permissions to setting up triggers in the Iroha network
• The user has permissions to execute all instructions which are included into the trigger body

Use case flow

• The trigger was configured and ready to fire

• The trigger was created and configured as "manual" by the FR0300
• The user has permissions to fire the trigger
• The user has ID of the target trigger

Use case flow

1. The user prepares the instruction to fire the target trigger
2. The user sends the instruction to the Iroha peer (<<include>> FR0100)
3. The Iroha peer returns result of the target trigger execution

• All instructions from the trigger body was executed and applied to the block storage

• On step 3, if user does not have permissions to run all instructions in the Trigger, the Iroha peer returns "not enough permissions" status; use case flow stops.

• The trigger was created by the FR0300
• The user has permissions to remove the trigger
• The user has ID of the target trigger

Use case flow

1. The user prepares the instruction to remove the trigger
2. The user sends the instruction to the Iroha peer (<<include>> FR0100)
3. The Iroha peer returns results of the instruction to the user

• The target trigger was removed from the list of active triggers

• On step 3, if the user does not have enough permissions, the Iroha peer will return "not enough permissions" error status; use case flow stops

Measurable characteristic of the response, which can be checked for understanding how the system satisfies the requirements

• Iroha 2 white-paper

• Iroha 2 white-paper