Iroha 2 requirements

The Iroha peer

One of active peers of the Iroha network, accessible by network for the current user.

The administrator

The user of the Iroha network with the extended rights towards manipulating the peers and network configuration

The user

Generic user of the Iroha network with common list of permissions (required permissions are always mentioned in the use case Preconditions)

Status

discuss

Reviewed

decided

postpone

Source

Source (or list of sources) of the function: project name / stakeholder name / document title (e.g., whitepaper) / etc.

Preconditions

• 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

Post-conditions

• List of post-conditions, one or more results of successfully finished use case

Alternative flow

• 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

Exception 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

Status

discuss

Source

• Generic blockchain functionality ( @Vadim Reutskiy)

Preconditions

• The administrator has configured environment for running Iroha executable

• The administrator has prepared the information for the network configuration (peer addresses and ports, consensus parameters, etc.)

• The administrator generated key pairs for all accounts, which should be created at the start of the network, including root administrator account if it is required by business requirements

• The administrator has prepared the genesis block configuration according to the network configuration and business requirements

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

Post-conditions

• The Iroha network is running

• The administrator has access to the root account of the network

Alternative flow

N/A

Exception flow

• 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

Status

discuss

Source

• Generic functionality ( @Vadim Reutskiy)

Preconditions

• 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

Post-conditions

• The new peer is added into the network

Alternative flow

N/A

Exception flow

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

Status

discuss

Source

• Basic blockchain functionality (@Vadim Reutskiy)

Preconditions

• The administrator has access to the account with permission of removing peers form the network

Use case flow

1. The administrator prepares the instruction to remove the peer from the Iroha network

2. The administrator sends the transaction with the prepared instruction to the Iroha peer

3. The Iroha peer confirms the execution of the instruction

Post-conditions

• The target peer is removed from the current Iroha network and all processes in consensus continues without it

Alternative flow

N/A

Exception flow

N/A

Status

discuss

Source

Preconditions

• The Iroha network is just started

Use case flow

TBD - questionable functionality

Post-conditions

• The Iroha network is configured according to the requirements

Alternative flow

N/A

Exception flow

N/A

Status

discuss

Source

• Sora 2 project

Preconditions

• The administrator has access to account with permissions to change the network configuration by sending the corresponding instruction

Use case flow

1. The administrator prepares the data for the instruction for changing the overall Iroha network configuration. Configuration may include
   
   

   1. Default time to life (TTL) for pending multi-signature transaction

   2. Maximum transactions in the single block

   3. Maximum time of block filling by transactions (in milliseconds)

   4. TBD

2. The administrator sends the transaction with prepared instruction to the Iroha peer (<<include>> FR0100)

3. The Iroha peer return the results of instruction execution to the administrator.

Post-conditions

• The network configuration is changed correspondingly

Alternative flow

N/A

Exception flow

N/A

Status

discuss

Source

• Generic peer functionality (@Vadim Reutskiy )

Preconditions

• The administrator has access to the maintenance endpoint of the target Iroha peer

Use case flow

1. The administrator connects to the maintenance endpoint of the target Iroha peer

2. The administrator performs requests to change required parameters of the target Iroha peer

3. The Iroha peer returns result of change operation to the administrator

Post-conditions

• The configuration of the target Iroha peer was changed

Alternative flow

N/A

Exception flow

• On step 3, if the value of changed configuration parameter is out of the limit, the Iroha peer will return "wrong parameter value" error status to the administrator; use case flow stops.

Status

discuss

Source

• Iroha 2 whitepaper (@武宮誠)

Preconditions

• 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

Post-conditions

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

Alternative flow

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

Exception flow

• 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

Status