Versions Compared

Old Version 38

changes.mady.by.user Vadim Reutskiy

Saved on

compared with

New Version 39

changes.mady.by.user Vadim Reutskiy

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Added use cases for CRUD operations of data associated with the account: FR0212, FR0213, FR0112


Page Properties


Target releaseIroha 2.0 MVP
Document status
Status
titleDRAFT
Document owner

Vadim Reutskiy

Tech lead

Nikita Puzankov

Developers

Egor Ivkov Михаил Болдырев

Blockchain advisorsKamil Salakhiev Andrei Lebedev
QAStephan Lavrentev


Goals

Background and strategic fit

Table of Contents


Expand
titleHistory of changes
Change History


Assumptions

Requirements

Functional requirements

For the functional requirements, we should follow the default use case template by example:

Use case title
[FR0000] Example use-case; ID should be unique
Status

Status
colourYellow
titlediscuss

Status
colourGreen
titledecided

Status
colourRed
titlepostpone

SourceSource (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
Postconditions
  • 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


Iroha network operations

Use case title
[FR0001] Starting the Iroha network
Status

Status
colourYellow
titlediscuss

Source
Preconditions
  • 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
Postconditions
  • The Iroha network is running
  • The administrator has access to the root account of the network
Alternative flow


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


Use case title
[FR0002] Adding peer to the Iroha network
Status

Status
colourYellow
titlediscuss

Source
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
Postconditions
  • The new peer is added into the network
Alternative flow
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


Use case title
[FR0003] Removing peer from the Iroha network
Status

Status
colourYellow
titlediscuss

Source
Preconditions

Use case flow


Postconditions
Alternative flow
Exception flow


Use case title
[FR0004] Configuring initial state of the Iroha network
Status

Status
colourYellow
titlediscuss

Source
Preconditions

Use case flow


Postconditions
Alternative flow
Exception flow


Making changes in Iroha network data by Iroha special instructions

Info

❇️❇️❇️

In this section all use cases related to changing data in the Iroha network will be described


Use case title
[FR0100] Sending the transaction to the Iroha network
Status

Status
colourYellow
titlediscuss

Source
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
Postconditions
  • 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


Use case title
[FR0101] Creation of the account in the Iroha network
Status

Status
colourYellow
titlediscuss

Source
Preconditions
  • The user has permission to create accounts

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
Postconditions
  • The new account in the Iroha network is created
Alternative flowN/A
Exception flow
  • 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.


Use case title
[FR0102] Configuring permissions for the account in the Iroha network
Status

Status
colourYellow
titlediscuss

Source
Preconditions
  • 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
Postconditions
  • The permissions of the target account was changed correspondingly
Alternative flowN/A
Exception flow
  • 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


Use case title
[FR0102] Granting permissions for the account in the Iroha network
Status

Status
colourYellow
titlediscuss

Source
  • ???
Preconditions
  • 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
Postconditions
  • The permission was granted to another account
Alternative flow
Exception flow
  • 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


Use case title
[FR0104] Sending complex instruction using ISI DSL
Status

Status
colourYellow
titlediscuss

Source
Preconditions
  • 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
Postconditions
  • The complex instruction was executed and applied to the Iroha network
Alternative flowN/A
Exception flow
  • 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.


Use case title
[FR0105] Sending instruction and subscribing to the status of finalization
Status

Status
colourYellow
titlediscuss

Source
Preconditions
  • 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
Postconditions
  • The instruction is accepted and finalized in the block-storage
  • The user did not spend additional resources for redundant network connections and requests
Alternative flow
Exception flow
  • 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.


Use case title
[FR0106] Creation of the multi-signature account in the Iroha network
Status

Status
colourYellow
titlediscuss

Source
Preconditions
  • 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
Postconditions
  • The new MST account with defined list of signatories and quorum is created
Alternative flowN/A
Exception flow
  • 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 title
[FR0107] Changing quorum for the multi-signature account
Status

Status
colourYellow
titlediscuss

Source
Preconditions
  • The user have access to the account with permissions to control the target MST account

Use case flow


Postconditions
  • The quorum for the target MST account was changed
Alternative flow
Exception flow


Use case title
[FR0108] Changing list of signatories for the multi-signature account
Status

Status
colourYellow
titlediscuss

Source
Preconditions
  • 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
Postconditions
  • List of signatories for the selected account was changed correspondingly
Alternative flowN/A
Exception flow
  • 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.


Use case title
[FR0109] Signing multi-signature transaction
Status

Status
colourYellow
titlediscuss

Source
  1. Iroha 2 whitepaper
  2. Iroha 1 approach
  3. Iurii Vinogradov
Preconditions
  • 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

  1. The user obtains the current list of pending transactions (<<include>> FR0203)
  2. The user finds the required transaction that can be signed by his/her signatures
  3. The user signs required transaction using the available key pair by calling the corresponding method from CLI or client SDK
  4. The user sends signed transaction to the Iroha peer (<<include>> FR0100)
Postconditions
  • 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
Alternative flow
  • On step 2 the user can select more than one transactions, all of them can be sent on step 4 as a separate requests
  • The user can skip steps 1 and 2 if he/she already has information about the pending transaction, which was provided by any external integration. Hence, the user need to have possibility to start the use case directly from the step 3 by sending signed transaction without prior queries. (by Yuriy Vinogradov)
  • On step 3 the user can sign the transaction by more than one signature, and all of them can be sent as a single request per single transaction on step 4. In bridge implementation scenario is: 1. Selected bridge get all bridge instances signatures from the block and calls an Iroha2 ISI with the transfer information, attaching all bridge nodes signatures. It can be implemented as in Iroha1 by sending multple ISI calls in one transaction or batch, or it can be implemented as One ISI call with multiple signatures. Iurii Vinogradov
Exception flow
  • On step 1, in case of the empty list of pending transactions, the Iroha peer will return corresponding status and the use case flow stops
  • On step 3, if the user uses key pair, which was already used for signing the transaction, the CLI/SDK will return corresponding error status; use case flow stops if there are no more available key pairs. 
    Status
    colourYellow
    titleTBD
     (define, will it be available to do on the client-side?)


Use case title
[FR0110] Changing the conditions for the multi-signature account
Status

Status
colourYellow
titlediscuss

Source
Preconditions
  • 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
Postconditions
  • The list of conditions for the target multi-signature account was changed correspondingly
Alternative flow
Exception flow


Use case title
[FR0111] Assigning weights to the signatories of the multi-signature account
Status

Status
colourYellow
titlediscuss

SourceBogdan Mingela
Preconditions
  • 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
Postconditions
  • The list of signatories weights and target quorum for the target multi-signature account was changed correspondingly
Alternative flowN/A
Exception flowN/A

Acquiring data from the Iroha network by queries


Use case title
[
FR0200] Acquiring data from the Iroha network by query
FR0112] Associating and changing arbitrary data payload with the account
Status

Status
colourYellow
titlediscuss

Source
  • Iroha 2 whitepaper
  • Generic functionality of Iroha
PreconditionsUser
Preconditions
  • The user has access to
the
  • account with permissions
, which allows to get results of target query
  • to change data payload related to the target account

Use case flow

  1. The user
sends the query
  1. prepares the key and value of the data payload for forming the corresponding instruction
  2. The user sends the transaction with prepared instruction to the Iroha peer
through the API
  1. (<<include>> FR0100)
  2. The Iroha peer
receives the query and validates its contents
  • The Iroha peer checks that the user's account have enough permissions to get all data requested in query
  • The Iroha peer collects information requested in query from the current WSV
  • The Iroha peer creates Merkle tree for the obtained data 
    Status
    colourYellow
    titleTBD
  • The Iroha peer returns the result of the operation to the user
    • PostconditionsUser receives the response with the requested data
    1. returns results of instruction to the user
    Postconditions
    • The data payload associated with the target account was changed correspondingly
    Alternative flow
    • On step 2, if there was no such key associated with the target account, the key will be created 
    • On step 2, if some value is already associated with the provided key, the value will be overwritten
    Exception flow
    • On step 2, if the size of payload data exceeds limit, the Iroha peer will return the "Too large data" error message; use case flow stops.

    Acquiring data from the Iroha network by queries

    Info

    ❇️❇️❇️

    In this section all use cases related to retrieving data from the Iroha network will be described


    Use case title
    [FR0200] Acquiring data from the Iroha network by query
    Status

    Status
    colourYellow
    titlediscuss

    Source
    • Iroha 2 whitepaper
    • Generic functionality of Iroha
    Preconditions
    • User has access to the account with permissions, which allows to get results of target query

    Use case flow

    1. The user sends the query to the Iroha peer through the API
    2. The Iroha peer receives the query and validates its contents
    3. The Iroha peer checks that the user's account have enough permissions to get all data requested in query
    4. The Iroha peer collects information requested in query from the current WSV
    5. The Iroha peer creates Merkle tree for the obtained data 
      Status
      colourYellow
      titleTBD
    6. The Iroha peer returns the result of the operation to the user
    Postconditions
    • User receives the response with the requested data
    Alternative flowN/A
    Exception flow
    • 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 title
    [FR0201] Acquiring the information about the selected account
    Status

    Status
    colourYellow
    titlediscuss

    Source
    Preconditions

    Use case flow


    Postconditions
    Alternative flow
    Exception flow


    Use case title
    [FR0202] Acquiring of the current permissions for the selected account
    Status

    Status
    colourYellow
    titlediscuss

    Source
    Preconditions

    Use case flow


    Postconditions
    Alternative flow
    Exception flow


    Use case title
    [FR0203] Acquiring a list of pending multi-signature instructions
    Status

    Status
    colourYellow
    titlediscuss

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

    Use case flow

    1. The user prepares query for requesting the list of the pending transaction
    2. The user sends the query to the Iroha peer (<<include>> FR0200)
    3. The user receives the list of currently pending multi-signature transaction  
      Status
      colourYellow
      titleTBD
       (should the Iroha expose all pending transactions, or we need to add the account ID / public key to filter the request?)
    Postconditions
    • The user has the list of currently pending instructions
    Alternative flowN/A
    Exception flow
    • On step 3, if there are no currently pending transactions, the Iroha peer will return "empty response" status


    Use case title
    [FR0204] Acquiring a list of current conditions for a multi-signature account
    Status

    Status
    colourYellow
    titlediscuss

    Source
    Preconditions
    • 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
    Postconditions
    • The user received the list of conditions for the target account
    Alternative flowN/A
    Exception flow
    • 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.3, if there are no currently configured conditions, the Iroha peer will return "empty response" status
    • On step 3, if the user's account does not have enough permissionsis not multi-signature, the Iroha peer returns error with corresponding status, use case execution stops.will return "not applicable" status


    Use case title
    [
    FR0201
    FR0205] Acquiring
    the information about the selected account
    a block by its number
    Status

    Status
    colourYellow
    titlediscuss

    Source

    Bogdan Mingela

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

    Use case flow

    		PostconditionsAlternative flowException flow
    Use case title
    [FR0202] Acquiring of the current permissions for the selected account
    Status

    Status
    colourYellow
    titlediscuss

    SourcePreconditions

    Use case flow

    		PostconditionsAlternative flowException flow
    1. The user prepares query for requesting the i-th block
    2. The user sends the query to the Iroha peer (<<include>> FR0200)
    3. The user receives the block description with all its' transactions etc
    Postconditions
    • The user receives the requested block from the blockstore
    Alternative flowN/A
    Exception flow
    • On step 3, if there are no block specified, the Iroha peer will return "error/no such block" response


    Source
    Use case title
    [
    FR0203
    FR0206] Acquiring
    a list of pending multi-signature instructions
    blocks subscription 
    Status

    Status
    colourYellow
    titlediscuss

     (can be extended with a start block number index)

    Source

    Bogdan Mingela

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

    Use case flow

    1. The user prepares query for requesting the list of the pending transactionsubscription of blocks
    2. The user sends establishes the query subscription to the Iroha peer (<<include>> FR0200)The user receives the list of currently pending multi-signature transaction  
      Status
      colourYellow
      titleTBD
       (should the Iroha expose all pending transactions, or we need to add the account ID / public key to filter the request?)query results with the Iroha peer (<<include>> FR0208)
    3. The user analyses the results of continuously received payload
    Postconditions
    • The user has the list of currently pending instructionsgot 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
    Alternative flowN/A
    Exception flowOn step 3, if there are no currently pending transactions, the Iroha peer will return "empty response" status

    N/A


    Use case title
    [
    FR0204] Acquiring a list of current conditions for a multi-signature account
    FR0207] Acquiring pending transactions subscription
    Status

    Status
    colourYellow
    titlediscuss

    Source
    Preconditions
    • The user has permissions to request a list of conditions to the target multi-signature accountthe list of pending transactions (subscription, can be separate permission or from <<include>> FR0203)

    Use case flow

    1. The user prepares query for
    requesting a list of currently configured conditions of signing for the target multi-signature account
    1. subscription for pending transactions
    2. The user
    sends the query to the
    1. established the subscription with the Iroha peer (
    <<include>> FR0200)The user receives the list of currently configured conditions of signing for the target multi-signature account
    1. <<include>> FR0208)
    2. The user gets the connection to receive pending transactions within initialized 
    Postconditions
    • The user received the list of conditions for the target account
    Alternative flowN/A
    Exception flow
    • 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" statushas got stable pending transactions perception channel and newly arriving pending transactions
    Alternative flowN/A
    Exception flowN/A


     (can be extended with a start block number index)[FR0207] Acquiring pending transactions subscription
    Use case title
    [
    FR0205] Acquiring a block by its number
    FR0208] Subscribing on the query results
    Status

    Status
    colourYellow
    titlediscuss

    Source
    Bogdan Mingela
    Preconditions
    • The user has permissions to request the block by its numberget results of the target query

    Use case flow

    1. The user prepares
    query for requesting the i-th block
  • The user sends the query to the Iroha peer (<<include>> FR0200)
  • The user receives the block description with all its' transactions etc
    		• PostconditionsThe user receives the requested block from the blockstore
    1. 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
    Postconditions
    • The user has continuous results of query execution
    Alternative flowN/A
    Exception flowStatus
    • On step 3, if
    there are no block specified, the Iroha peer will return "error/no such block" response
    Use case title
    [FR0206] Acquiring blocks subscription 
    • the Iroha peer experiences issues with the network connection to other peers, the flow of results may be unplugged 
      Status
      colourYellow
      title
    		discuss
    Source

    Bogdan Mingela

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

    Use case flow

    1. The user prepares query for subscription of blocks
    2. The user establishes the subscription to the query results with the Iroha peer (<<include>> FR0208)
    3. The user analyses the results of continuously received payload
    Postconditions
    • 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
    Alternative flowN/A
    Exception flow

    N/A

    Use case title
    • TBD
    • On step 3, if the user experiences issues with the network connection to the Iroha peer, the flow of results will be interrupted
    • On step 3, if the user experiences issues with the network connection to the Iroha peer, the flow of results will be interrupted


    Use case title
    [FR0209] Validate result of the query
    Status

    Status
    colourYellow
    titlediscuss

    Source

    Kamil Salakhiev, Sora project (

    by Bogdan Mingela

    by Ruslan Rezin )

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

    Use case flow

    1. The user prepares
    query for subscription for pending transactions
    1. request data for the target query
    2. The user
    established the subscription with the 
    1. sends the query to the Iroha peer (<<include>>
    FR0208)
  • The user gets the connection to receive pending transactions within initialized 
    • Postconditions
    • The user has got stable pending transactions perception channel and newly arriving pending transactions
    Alternative flowN/A
    Exception flowN/A
    1. FR0200)
    2. 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
    3. The user receives the response and validates the correctness of the data by checking Merkle proof and obtained data
    Postconditions
    • The user has result of the query request with merkle proof of its validity
    Alternative flowN/A
    Exception flow
    • On step 4, if the response was corrupted or changed, the user can find it by comparing results of data hashing with the Merkle proof. In that case, validation can be considered as failed.


    Use case title
    [
    FR0208] Subscribing on the query results
    FR0210] Query old Iroha state (e.g., query balance month ago)
    Status

    Status
    colourYellow
    titlediscuss

    Source
    Preconditions
    Preconditions
    • The user has access to account with permissions to get requested data at the current moment 
      Status
      colourYellow
      titleTBD
    • The user has access to account which had permissions to get
    results of the target query
    • requested data at the moment in the past, requested by the user

    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
    		PostconditionsThe user has continuous results of query execution

    <<extends>> FR0200, substitutes step 4:

    1. The Iroha peer collects data from the block storage at the moment, requested in the query
    Postconditions
    • The user received the requested information about the information in block store on the provided date
    Alternative flowN/A
    Exception flow
  • On step 3, if the Iroha peer experiences issues with the network connection to other peers, the flow of results may be unplugged 
    Status
    colourYellow
    titleTBD
    • On step 3, if the user experiences issues with the network connection to the Iroha peer, the flow of results will be interruptedException flow
    • On step 31, if the user experiences issues with the network connection to there is no data for the requested query on the required date, the Iroha peer , the flow of results will be interruptedwill return error response with corresponding state


    Kamil Salakhiev, Sora project (by Ruslan Rezin )
    Use case title
    [
    FR0209
    FR0211]
    Validate result
    Querying list of accounts with the
    query
    predefined filter
    Status

    Status
    colourYellow
    titlediscuss

    		Source

     - probably optional for MVP, if there will be another way for gathering data for the award calculation for liquidity providers

    Source
    Preconditions
    • The user has permissions to get results of perform the target queryquery
    • The user has list of conditions which need to be used for filtering accounts

    Use case flow

    1. The user prepares request data for the target querythe query and adds the filtering setup to the query body
    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-storeexecution to the user
    Postconditions
    • The user
    receives the response and validates the correctness of the data by checking Merkle proof and obtained data
    Postconditions
    • The user has result of the query request with merkle proof of its validity
    Alternative flowN/A
    • has the list of accounts which satisfies entered filter
    Alternative flow
    • On step 1, the user can include the query to the DSL sequence as a part of the complex instruction
    Exception flow
    • On step
    4
    • 3, if the
    response was corrupted or changed, the user can find it by comparing results of data hashing with the Merkle proof. In that case, validation can be considered as failed
    • user does not have enough permissions, the Iroha peer returns "not enough permission" error status; the use case flow stops.


    Use case title
    [
    FR0210] Query old Iroha state (e.g., query balance month ago)
    FR0212] Retrieving the list of keys of data payload, associated with the target account
    Status

    Status
    colourYellow
    titlediscuss

    Source
    Iroha community (by Kamil Salakhiev
    Preconditions
    • The user has access to account with permissions to
    get requested data at the current moment 
    Status
    colourYellow
    titleTBD
    The user has access to account which had permissions to get requested data at the moment in the past, requested by the user
    • retrieve data payload related to the target account

    Use case flow

    <<extends>> FR0200, substitutes step 4:
    1. The user prepares the target account identifier for forming the corresponding query
    2. The user sends the transaction with prepared query to the Iroha peer (<<include>> FR0200)
    3. The Iroha peer
    collects data from the block storage at the moment, requested in the query
    1. returns results of query to the user, which contains the list of keys, associated with the target account
    Postconditions
    • The user
    received the requested information about the information in block store on the provided date
    • acquired list of keys of data payload associated with the target account 
    Alternative flow

    N/A

    Exception flow
    • On step
    1
    • 2, if there is no
    data for the requested query on the required date
    • keys associated with the target account, the Iroha peer will return
    error response with corresponding state
    • "No data" status message; use case flow stops.


    Use case title
    [
    FR0211] Querying list of accounts with the predefined filter
    FR0213] Retrieving the value of data payload by the key, associated with the target account
    Status

    Status
    colour

    Yellowtitlediscuss - probably optional for MVP, if there will be another way for gathering data for the award calculation for liquidity providers

    Yellow
    titlediscuss

    Source
    Internal
    • Sora 2 project
    by Yuriy Vinogradov
    Preconditions
    • The user has access to account with permissions to
    perform the query
  • The user has list of conditions which need to be used for filtering accounts
    • retrieve data payload related to the target account

    Use case flow

    1. The user prepares the
    query and adds the filtering setup to the query body
    1. target account identifier and required key for forming the corresponding query
    2. The user sends the transaction with prepared query to the Iroha peer (<<include>> FR0200)
    3. The Iroha peer returns
    result of the query execution to the user
    1. results of query to the user, which contains value of data payload, associated with target key on target account
    Postconditions
    • The user
    has the list of accounts which satisfies entered filterAlternative flowOn step 1, the user can include the query to the DSL sequence as a part of the complex instruction
    • acquired value of data payload, associated with target key on target account
    Alternative flow

    N/A

    Exception flow
    • On step
    3
    • 2, if
    the user does not have enough permissions
    • there is no such keys associated with the target account, the Iroha peer
    returns "not enough permission
    • will return "Wrong key" error
    status
    • message;
    the
    • use case flow stops.

    Setting up and executing triggers

    Use case title
    [FR0300] Setting up a trigger in the Iroha network
    Status

    Status
    colourYellow
    titlediscuss

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

    Use case flow

    1. The user prepares the list of instructions in form of DSL sequence
    2. The user prepares the instruction for sending trigger body to the Iroha peer
      1. The user can configure trigger to fire in manual mode only, by sending specific instruction to the Iroha peer;
      2. The user can configure trigger to fire when the temporal condition becomes true; condition can be based on the block number or block timestamp;
      3. The user can configure trigger to fire when the data condition becomes true; condition can be based on the data available by permissions to the author user; 
        Status
        colourYellow
        titleTBD
         (potential problem with the performance)
    3. The user sends the instruction to the Iroha peer (<<include>> FR0100)
    4. The Iroha peer returns result of trigger setup to the user, which includes ID of the trigger which can be used to manually fire the trigger in future
    5. The Iroha peer checks the conditions of the triggers periodically; if the condition becomes true, the Iroha peer checks permissions of the author user and executes the trigger body
    Postconditions
    • The trigger was configured and ready to fire
    Alternative flowN/A
    Exception flow
    • On step 4, if the user does not have permissions to set up triggers and/or if there is not enough permissions to each command in the trigger body, the Iroha peer return "not enough permissions" error response; use case flow stops.
    • On step 5, if permissions of the author user would not allow for all instructions to execute (for example, if permissions of the author user was changed after creating the trigger), the whole trigger execution will be cancelled. 
      Status
      colourYellow
      titleTBD


    Use case title
    [FR0301] Manually firing the trigger
    Status

    Status
    colourYellow
    titlediscuss

    Source
    Preconditions
    • 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
    Postconditions
    • All instructions from the trigger body was executed and applied to the block storage
    Alternative flowN/A
    Exception flow
    • 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.


    Use case title
    [FR0302] Removing the trigger
    Status

    Status
    colourYellow
    titlediscuss

    Source
    Preconditions
    • 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
    Postconditions
    • The target trigger was removed from the list of active triggers
    Alternative flowN/A
    Exception flow
    • 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

    Non-functional requirements

    Non-functional requirements (also named as "Quality attributes") describes the behavior of the system not directly related to the functions of the system, but answers the question "How system works?". The template for all quality attributes should follow the example (link to source):

    Quality attribute name
    [NFR0000] Example quality attribute; ID should be unique
    Status

    Status
    colourYellow
    titlediscuss

    Status
    colourGreen
    titledecided

    Status
    colourRed
    titlepostpone

    SourceSource (or list of sources) of the quality characteristic: project name / stakeholder name / document title (e.g., whitepaper) / etc.
    Source of stimulusEntity, which initiates the stimulus, may be one of system users, another software system, etc.
    StimulusCondition, which requires the response from the system
    EnvironmentDefinition of specific conditions when stimulus occurs, and which is important for the result of response. Typical environment values are: normal operation, overload of requests, starting up the system, etc.
    ArtifactParticular subject of stimulus, may be the whole system, some subset of parts or single part of the system.
    ResponseResult of reaction of the system to the stimulus
    Response measure

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


    Performance

    Quality attribute name
    [NFR0001] Transaction processing speed
    Status

    Status
    colourYellow
    titlediscuss

    Source
    Source of stimulusClient applications of the Iroha network
    StimulusClient application sends transactions to the Iroha network
    EnvironmentNormal operation of the system
    ArtifactWhole Iroha network
    ResponseThe Iroha peer accepts the transactions and adds them to the blockchain
    Response measureThe Iroha network should process at least 20.000 transactions per second


    Quality attribute name
    [NFR0001] Delay of block creation
    Status

    Status
    colourYellow
    titlediscuss

    Source
    Source of stimulusClient applications of the Iroha network
    StimulusClient application sends transactions to the Iroha network
    EnvironmentNormal operation of the system
    ArtifactWhole Iroha network
    ResponseThe Iroha peer accepts the transactions and to the block
    Response measureThe Iroha network should create new block each 2-3 seconds







    Questions

    Below is a list of questions to be addressed as a result of this requirements document:

    QuestionOutcome

    Not Doing