Versions Compared

Old Version 9

changes.mady.by.user Vadim Reutskiy

Saved on

compared with

New Version 10

changes.mady.by.user Vadim Reutskiy

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Making changes in Iroha network data by Iroha special instructions

Use case title
[FR0100] Sending the
instruction
transaction to the Iroha network
Preconditions
  • The user has an account in the Iroha network
  • The user has prepared the commandtransaction for sending; transactions can consist of several instructions
  • The user has permissions to execute all instruction included in the instructiontransaction
  • The Iroha network is working in normal condition

Use case flow

  1. The user sends the instruction transaction to the Iroha peer through the API
  2. The Iroha peer receives the instruction 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 instructiontransaction
  4. The Iroha peer executes the instruction transaction by applying it to the current block
  5. The Iroha peer returns the result of the operation to the user
Postconditions
  • The instruction 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 instruction will 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 instruction instructions has invalid structure, the Iroha peer returns an error message with description to the users 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 instructiontransaction, 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 user in the Iroha network
Preconditions
  • 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 (includes <<include>> FR0100)
  4. Tha Iroha peer returns the result of the instruction execution to the user
Postconditions
  • The new account in the Iroha network is created
Alternative flow
Exception flow

...

Use case title
[FR0108] Changing list of signatories for the multi-signature account
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 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 is 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
instruction
transaction
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 instruction transaction is lower than a current quorum value

Use case flow

  1. The user obtains the current list of pending instructions transactions (<<include>> FR0203)
  2. The user finds information the required instruction transaction that can be signed by his/her signatures
  3. The user signs required instruction transaction using the available key pair by calling the corresponding method from CLI or client SDK
  4. The user sends signed instructions 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 instruction, all of them can be sent on step 4 as a separate requests
  • On step 3 the user can sign the instruction by more than one signature, and all of them can be sent as a single request per single instruction on step 4
Exception flow
  • On step 1, in case of the empty list of pending instructions, 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 instruction, 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
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 prepared 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


Acquiring data from the Iroha network by queries

...

Use case title
[FR0203] Acquiring a list of pending multi-signature instructions
Preconditions
  • The user has permissions to request the list of pending instructions

Use case flow

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


Use case title
[FR0204] Acquiring a list of current conditions for a multi-signature account
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 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

Non-functional requirements

...