...
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
| Block Synchronization | //TODO Egor Ivkov please add small note about the gossip design and concerns. | | 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-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 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 | 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 | Mechanism 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 |
| |
GreenMUSTGreenMUSTGreenMUSTNon-Functional
Security
Maintenance
Target Platforms
Iroha deployment should support GNU/Linux, MacOS 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
...
- 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 Removed
Image Added
Questions
Below is a list of questions to be addressed as a result of this requirements document:
...