...
Background and strategic fit
...
Assumptions
...
Peer to peer communication
ID | Item | EPIC | Importance | Status | ADR/RFC |
---|
Brief description | NotesIroha should 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. should 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 | |
|
| Iroha |
should 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 |
should 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 | NotesIroha should have an in-memory representation of the World State View for optimization of access and change time.Iroha should 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.Iroha should perform seamless synchronization of block storage between peers, so | //TODO Egor Ivkov please add a 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 | | Status |
---|
| |
---|
colour | Blue |
---|
title | IN-PROGRESS |
---|
|
| Permissions |
and Event Listeners | 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 | 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 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 Removed
Image Added
Questions
Below is a list of questions to be addressed as a result of this requirements document:
...