Page History

...

Goals

• Simplify usage of Iroha in comparison with 1.* version

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

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

• 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.

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

Blocks storage

Consensus

Queries

Smart Contracts

Modules

Maintenance

Clients

User interaction and design

Image Removed

Iroha application crate

.
├── Cargo.toml
├── config.json
├── docs
│   └── references
└── src
    ├── account.rs
    ├── asset.rs
    ├── block.rs
    ├── config.rs
    ├── crypto.rs
    ├── domain.rs
    ├── isi.rs
    ├── kura.rs
    ├── lib.rs
    ├── main.rs
    ├── merkle.rs
    ├── peer.rs
    ├── query.rs
    ├── queue.rs
    ├── sumeragi.rs
    ├── torii.rs
    ├── tx.rs
    └── wsv.rs

Network crate

.
├── Cargo.toml
└── src
    └── lib.rs

Macroses

.
├── Cargo.toml
├── iroha_derive
│   ├── Cargo.toml
│   ├── src
│   │   └── lib.rs
│   └── tests
│       ├── log.rs
│       └── serialize.rs
└── src
    └── lib.rs

Iroha clients

Iroha Rust Client

.
├── benches
│   └── torii.rs
├── Cargo.toml
├── config.json
├── src
│   ├── client.rs
│   └── lib.rs
├── target
│   └── criterion
└── tests
    ├── add_asset.rs
    ├── high_load_transfer.rs
    └── transfer_asset.rs

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.

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

• Transaction performance benchmarking framework
• Memory usage benchmarking framework

Maintenance

• Logging - 

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

• Service Discovery

Continuous Delivery

• Docker images publish
• Binary and documentation publish

Longevity Stand

• HI2-41

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

Image Added

...

Questions

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

Not Doing

• Genesis Block