You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 13 Next »

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

Functional

Peer to Peer Network

ItemEPICImportanceNotes
Peer to Peer Network LibraryHI2-6

MUST

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








Blocks Storage

ItemEPICImportanceNotes
World State View

MUST

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

HI2-1

HI2-17

HI2-18

MUST

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

MUST

//TODO Egor Ivkov please add small note about the gossip design and concerns.

Smart Contracts

ItemEPICImportanceNotes
Iroha Special Instructions mechanism

MUST


Out of the box set of Iroha Special Instructions

HI2-28

HI2-29

HI2-35

MUST

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

Non Functional

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.

#TitleUser StoryImportanceNotes
1Storagehttps://soramitsucoltd.aha.io/features/HI2-1

MUST

  • Drive and In-Memory storage capabilities
2Permissionshttps://soramitsucoltd.aha.io/features/HI2-36

MUST

  • Already implemented in the way, required by internal projects
3Event Listenershttps://soramitsucoltd.aha.io/features/HI2-37

COULD


4Maintenance Endpoint

https://soramitsucoltd.aha.io/features/HI2-26

https://soramitsucoltd.aha.io/features/HI2-27

MUST

Maintenance Endpoint
5Transactions TTL

MUST

  • Discussed in chat, Nikita Puzankov will create an RFC based on the discussion

User interaction and design

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 requirements


Questions

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

QuestionOutcome

Not Doing

  • No labels