Page tree
Skip to end of metadata
Go to start of metadata
Target release2.0.0
Epic
Document status
DRAFT
Document owner
Designer
Developers
QA

Goals

Hyperledger Iroha v2 aims to be an even more simple, highly performant distributed ledger platform than Iroha v1. V2 carries on the tradition of putting on emphasis on having a library of pre-defined smart contracts in the core, so that developers do not have to write their own code to perform many tasks related to digital identity and asset management.

Background and strategic fit

https://github.com/hyperledger/iroha/blob/iroha2-dev/iroha_2_whitepaper.md#11-relationship-to-hyperledger-fabric-hyperledger-sawtooth-hyperledger-besu-and-others

Assumptions

Requirements

Sources

There are the following sources for all requirements:

  1. The main source of core structure: Iroha 2 white paper, authored by Makoto Takemiya
  2. List of requests from the Soramitsu projects regarding features
  3. Decisions made during the discussion, which are fixed in the list of RFCs

Functional

Peer to peer communication

IDItemEPICImportanceStatusADR/RFCNotes
IF2-100Peer 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-101Transactions Time to LiveHI2-38

MUST


Prevent replay of rejected transactionsIroha 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-102Multisignature TransactionsHI2-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-103Transaction 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

Blocks storage

IDItemEPICImportanceStatusADR/RFCNotes
IF2-200World State View

MUST

DONE


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

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-202Blocks 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-203Merkle Tree

MUST

DONE

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

Consensus

IDItemEPICImportanceStatusADR/RFCNotes
I2-300SumeragiHI2-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.

Queries

IDItemEPICImportanceStatusADR/RFCNotes
I2-400Iroha QueriesHI2-31

MUST

DONE


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

Smart Contracts

IDItemEPICImportanceStatusADR/RFCNotes
IF2-500Iroha Special Instructions mechanism

MUST

DONE



IF2-501Out 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-502PermissionsHI2-36

MUST

IN-PROGRESS

PermissionsPermissions in Iroha implemented based on Assets and Iroha Special Instructions.
IF2-503TriggersHI2-37

MUST

IN-PROGRESS

TriggersTriggers in Iroha implemented based on Assets and Iroha Special Instructions.
IF2-504Domain-Specific Language

COULD


Iroha Special Instructions DSLCustom Iroha Special Instructions and usage of the full set of Iroha Special Instructions should be easy for developers.
IF2-505Advanced Permissions Model

COULD

IN-PROGRESS

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

Modules

IDItemEPICImportanceStatusADR/RFCNotes
IF2-600Bridge

MUST

IN-PROGRESS

BridgesThe mechanism for communication between third-party blockchains.

DEX

MUST

IN-PROGRESS

DEX Generic ScenariosThe ability to exchange assets between accounts.

Maintenance

IDItemEPICImportanceStatusADR/RFCBrief descriptionNotes
IF2-700Maintenance 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.).

Clients

IDItemEPICImportanceStatusADR/RFCNotes

HTTP API

MUST

IN-REVIEW

Iroha API for ClientsBecause of clients restrictions decision about HTTP API was pushed forward.
IF2-800Rust Client LibraryHI2-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-802Mobile SDK

HI2-33

HI2-9

HI2-8

COULD

CANCELLED



IF2-803Web SDK

HI2-34

HI2-10

COULD

CANCELLED

Web API

Non-Functional

Security

Maintenance

Target Platforms

Iroha deployment should support GNU/Linux, macOS and Windows machines with x86 and Arm64 CPUs.

Transactions Processing

Iroha Peer should be able to process 20,000 transactions per second.

Blocks Processing

Iroha should be able to commit a new block every 3 seconds.

Development related

Benchmarks

Maintenance

  • Logging -  IR-832 - Getting issue details... STATUS
  • Service Discovery

Continuous Delivery

  • Docker images publish
  • Binary and documentation publish

Longevity Stand

Distributed testing

  • 10 servers, each on a different machine and in different geographies.
  • Run data through them for several minutes to really get some meaningful data.
  • Here is what each peer should do:
    - sync with peers about the latest blocks
    - gossip about (forward) transactions that are pending that they have
    - propose or vote on a block (as part of consensus)
    - ping and verify peers as part of the Hijiri reputation system (basically something like eigentrust++)
    - share time information as part of a p2p network time service

User interaction and design

Questions

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

QuestionOutcome

Not Doing

  • Genesis Block