Needs and Requirements

IF2-100

Peer to Peer Network Library

HI2-6

HI2-30

MUST

DONE

Networking stack

Plain TCP\IP based protocol with SCALE as de\serialization format.

Iroha must have a specific peer-to-peer protocol for effective communication and provided it as a detachable library.

IF2-101

Transactions Time to Live

HI2-38

MUST

Prevent replay of rejected transactions

Iroha must provide the possibility to explicitly state time-to-live (TTL) for each transaction, so the clients can set time interval in which transactions should be confirmed and put into the block store or removed from the queue by timeout.

IF2-102

Multisignature Transactions

HI2-13

MUST

Iroha must provide the possibility to configure each account to have a list of signatories, which needs to provide their signatures to confirm the transaction.

Also, Iroha should provide the possibility to perform conditional multi-signature transactions, so the conditions will automate transaction creation or signing them

IF2-103

Transaction dependencies

not defined

Transaction tags

(Proposed by Kamil') Iroha may provide a possibility to perform tag-based dependencies between transactions for making their sequence configurable by the client

IF2-200

World State View

MUST

DONE

In-memory, read fast data representation of the current World's State.

IF2-201

Kura

HI2-1

HI2-17

HI2-18

HI2-5

MUST

DONE

Kura is a decorator on top of Disk Block Storage and provides validation and World State View synchronization functionality. 

IF2-202

Blocks Synchronization

HI2-2

HI2-43

MUST

DONE

Block Synchronization

Peers periodically gossip with each other, sharing the latest block hash. If the hashes differ, then the peers discover they are out of sync and request synchronization.

IF2-203

Merkle Tree

MUST

DONE

Merkle Tree

Iroha provides a general purpose implementation of a Merkle Tree, which is used to verify the state of committed blocks and their transactions.

I2-300

Sumeragi

HI2-3

MUST

DONE

Iroha must have a reliable BFT consensus of blocks between all peers, which should keep effectively prevent attacks and malfunctioning in case of n of 2n+1 nodes are malicious/failing.

(details of Sumeragi are described in the white paper)

Sumeragi should be implemented as a detachable component and be available as a library, so other Hyperledger solutions can reuse it.

I2-400

Iroha Queries

HI2-31

MUST

DONE

Iroha Queries provide information about World State View based on client permissions.

IF2-500

Iroha Special Instructions mechanism

MUST

DONE

IF2-501

Out of the box set of Iroha Special Instructions

HI2-28

HI2-29

HI2-35

MUST

DONE

Several Tiers of Iroha Special Instructions provide:

• Basic building blocks that can be used to build Custom Iroha Special Instructions

• Maintenance-related Iroha Special Instructions (Add Peer, Change Build Block Time, etc.)

• "Iroha Modules"-related Iroha Special Instructions (Bridge, DEX, etc.)

IF2-502

Permissions

HI2-36

MUST

IN-PROGRESS

Permissions

Permissions in Iroha implemented based on Assets and Iroha Special Instructions.

IF2-503

Triggers

HI2-37

MUST

IN-PROGRESS

Triggers

Triggers in Iroha implemented based on Assets and Iroha Special Instructions.

IF2-504

Domain-Specific Language

Could

Iroha Special Instructions DSL

Custom Iroha Special Instructions and usage of the full set of Iroha Special Instructions should be easy for developers.

IF2-505

Advanced Permissions Model

Could

IN-PROGRESS

Expand Iroha Permission model

Full-fledged rights model in Iroha will greatly reduce the amount of server development for Iroha-based applications.

IF2-600

Bridge

MUST

IN-PROGRESS

Bridges

The mechanism for communication between third-party blockchains.

DEX

MUST

IN-PROGRESS

DEX Generic Scenarios

The ability to exchange assets between accounts.

IF2-700

Maintenance Endpoint

HI2-26

HI2-27

HI2-46

MUST

IN-PROGRESS

Maintenance Endpoint

Iroha must provide a maintenance endpoint, which can be used for performing operations (control over node status), requesting statistics and health information and subscribing on the updates (new blocks, transaction status changes, etc.).

HTTP API

MUST

IN-REVIEW

Iroha API for Clients

Because of clients restrictions decision about HTTP API was pushed forward.

IF2-800

Rust Client Library

HI2-32

MUST

DONE

Iroha Client encapsulates network-related functionality and provides "local" Rust Interface for:

• Submitting of Iroha Special Instructions to Iroha Peer

• Querying Data from Iroha Peer

• Maintenance Endpoint API

IF2-801

`no-std` client

Could

CANCELLED

Migration from Strings

IF2-802

Mobile SDK

HI2-33

HI2-9

HI2-8

Could

CANCELLED

IF2-803

Web SDK

HI2-34

HI2-10

Could

CANCELLED

Web API