Page History

...

Background and strategic fit

...

Iroha2 Whitepaper

Assumptions

Users will work with provided client libraries (iOS, Android, JS).
3f+1 nodes are enough to tolerate f Byzantine nodes in the network.
Iroha uses a simple data model made up of domains, peers, accounts, assets, signatories, and permissions, as shown in the figure below - all other entities are built on top of them.

...

Peer to peer communication

ID	Item	EPIC	Importance	Status	ADR/RFC

Brief description

Notes

IF2-100

Peer to Peer Network Library

HI2-6

HI2-30

Status


colour	Green
title	MUST

Status


colour	Green
title	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

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

.

IF2-101

Transactions Time to Live

HI2-38

Status


colour	Green
title	MUST

Prevent replay of rejected transactions

Iroha must provide the possibility to explicitly state time-to-live (TTL) for each transaction, so the clients

will have control over the

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

Status


colour	Green
title	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

Status

title	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

ID	Item	EPIC	Importance	Status	ADR/RFC

Brief description

Notes

IF2-200

World State View

Status


colour	Green
title	MUST

Iroha must have an in-memory representation of the World State View for optimization of access and change time.

Status


colour	Green
title	DONE

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

IF2-201

Status


colour	Green
title	MUST

Iroha must have abstraction over the disk-based block storage, which will cover all validation- and world-state-view-related functionality.

Iroha should have the Kura as a detachable library, so other Hyperledger solutions can easily reuse it.//TODO Egor Ivkov please add a small note about the gossip design and concerns

Status


colour	Green
title	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

Status


colour	Green
title	MUST

Status


colour	Green
title	DONE

Block Synchronization

Iroha must perform seamless synchronization of block storage between peers, so new peers or lagging ones will quickly synchronize their state with the network and join the decision-making process in consensus.

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

Status


colour	Green
title	MUST

Status


colour	Green
title	DONE

Merkle Tree

//TODO: Egor Ivkov , may I ask you to fill that?

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

Consensus

ID	Item	EPIC	Importance	Status	ADR/RFC

Brief description

Notes

I2-300

Sumeragi

HI2-3

Status


colour	Green
title	MUST

Status


colour	Green
title	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

ID	Item	EPIC	Importance	Status	ADR/RFC

Brief description

Notes

I2-400

Iroha Queries

HI2-31

Status


colour	Green
title	MUST

Iroha must provide a set of queries, which will cover the acquisition of all client-related data about all existing entities.

Status


colour	Green
title	DONE

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

Smart Contracts

ID	Item	EPIC	Importance	Status	ADR/RFC

Brief description

Notes

IF2-500

Iroha Special Instructions mechanism

Status


colour	Green
title	MUST

Iroha must provide a possibility to create various instructions to cover

Status


colour	Green
title	DONE

IF2-501

Out of the box set of Iroha Special Instructions

HI2-28

HI2-29

HI2-35

Status


colour	Green
title	MUST

Status


colour	Green
title	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

Status


colour	Green
title	MUST

Permissions and Event Listeners

Status


colour	Blue
title	IN-PROGRESS

Permissions

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

IF2-503

Triggers

HI2-37

Status


colour	Green
title	MUST

Status

colour

Yellow

title
Blue

Could

IN-PROGRESS

Triggers

Permissions and Event Listeners

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

IF2-504

Domain-Specific Language

Status


colour	Yellow
title	Could

Iroha Special Instructions DSL

Structure

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

IF2-505

Advanced Permissions Model

Status


colour	Yellow
title	Could

Status


colour	Blue
title	IN-PROGRESS

Expand Iroha Permission model

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

Modules

Brief description

ID

Item

EPIC

Importance

Status

ADR/RFC

Notes

IF2-600

Bridge

Status


colour	Green
title	MUST

Bridges

Status


colour	Blue
title	IN-PROGRESS

BridgesIroha must provide the possibility to TBD

The mechanism for communication between third-party blockchains.

DEX

Status


colour	Green
title	MUST

Status


colour	Blue
title	IN-PROGRESS

DEX Generic Scenarios

The ability to exchange assets between accounts.

Maintenance

ID

Item

EPIC

Importance

Status

ADR/RFC

Brief description

Notes

IF2-700

Maintenance Endpoint

HI2-26

HI2-27

HI2-46

Status


colour	Green
title	MUST

Status


colour	Blue
title	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

ID	Item	EPIC	Importance	Status	ADR/RFC

Brief description

Notes

HTTP API

Status


colour	Green
title	MUST

Status


colour	Yellow
title	IN-REVIEW

Iroha API for Clients

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

Notes

IF2-800

Rust Client Library

HI2-32

Status


colour	Green
title	MUST

Status


colour	Green
title	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

Status

colour

	Yellow
title	Could

Status


colour	Red

Green

title

MUST

CANCELLED

Migration from Strings

IF2-802

Mobile SDK

HI2-33

HI2-9

HI2-8

Status


colour	Yellow
title	Could

Status

colour

Green

title
Red

MUST

CANCELLED

IF2-803

Web SDK

HI2-34

HI2-10

Status


colour	Yellow
title	Could

Status

colour

Green

title
Red

MUST

CANCELLED

Web API

Non-Functional

Security

Support configurable crypto algorithms
Support for server-side HSM integration
Security and consistency improvements
Encapsulation of crypto-related functionality
Transport Layer Security Configuration

Maintenance

Logging

Target Platforms

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

...

Maintenance

Logging -
Jira
server Hyperledger JIRA
serverId 6326cb0b-65b2-38fd-a82c-67a89277103b
key IR-832
Service Discovery

...

User interaction and design

Image RemovedImage Added

Questions

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

...

Page tree

Versions Compared

Old Version 34

New Version Current

Key

Background and strategic fit

Assumptions

Peer to peer communication

Blocks storage

Consensus

Queries

Smart Contracts

Modules

Maintenance

Clients

Non-Functional

Security

Maintenance

Target Platforms

Maintenance

User interaction and design

Questions