...
Page properties |
---|
Target release | 2.0.0 |
---|
Epic |
|
---|
Document status | |
---|
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
...
Assumptions
Requirements
Sources
There are the following sources for all requirements:
- The main source of core structure: Iroha 2 white paper, authored by Makoto Takemiya
- List of requests from the Soramitsu projects regarding features
- Decisions made during the discussion, which are fixed in the list of RFCs
Functional
Peer to
...
peer communication
...
|
| 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 |
| |
| 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
//TODO Egor Ivkov please add small note about the gossip design and concerns. | ...
| 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 |
| | | 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. |
Consensus
ID | Item | EPIC | Importance | Status | ADR/RFC | Notes |
---|
I2-300 | Sumeragi | HI2-3 | | |
| 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 | Notes |
---|
I2-400 | Iroha Queries | HI2-31 | | |
| Iroha Queries provide information about World State View based on client permissions. |
Smart Contracts
ID | Item | EPIC | Importance | Status | ADR/RFC | Notes |
---|
IF2-500 | Iroha Special Instructions mechanism |
| | |
|
|
IF2-501 | Out of the box set of Iroha Special Instructions | HI2-28 HI2-29 HI2-35 | | |
| 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 | | |
Permissions and Event Listeners | Permissions | Permissions in Iroha implemented based on Assets and Iroha Special Instructions. |
IF2-503 | Triggers | HI2-37 | | |
YellowCould | Permissions and Event Listeners | Triggers in Iroha implemented based on Assets and Iroha Special Instructions. |
IF2-504 | Domain-Specific Language |
| |
| 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 |
| | 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
ID | Item | EPIC | Importance | Status | ADR/RFC | Notes |
---|
IF2-600 | Bridge |
| | Status |
---|
| |
---|
colour | Blue |
---|
title | IN-PROGRESS |
---|
|
| Bridges | The mechanism for communication between third-party blockchains. |
| DEX |
| | 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 | 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 | Notes |
---|
| HTTP API |
| | Status |
---|
| |
---|
colour | Yellow |
---|
title | IN-REVIEW |
---|
|
| Iroha API for Clients | Because of clients restrictions decision about HTTP API was pushed forward. |
IF2-800 | Rust Client Library | HI2-32 | | |
| 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 |
| | | Migration from Strings |
|
IF2-802 | Mobile SDK | HI2-33 HI2-9 HI2-8 | |
GreenMUSTNon-Functional
Security
Maintenance
Target Platforms
Iroha deployment should support GNU/Linux, MacOS 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 -
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
User interaction and design
Image Removed
Iroha application crate
No Format |
---|
.
├── 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
No Format |
---|
.
├── Cargo.toml
└── src
└── lib.rs
|
Macroses
No Format |
---|
.
├── Cargo.toml
├── iroha_derive
│ ├── Cargo.toml
│ ├── src
│ │ └── lib.rs
│ └── tests
│ ├── log.rs
│ └── serialize.rs
└── src
└── lib.rs
|
Iroha clients
Iroha Rust Client
No Format |
---|
.
├── 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
|
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