| 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
...
Peer to peer communication
| ID | Item | EPIC | Importance | ADR/RFC | Brief description | Notes |
|---|
| IF2-100 | Peer to Peer Network Library | HI2-6 HI2-30 | | Networking stack | Iroha should 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. |
| IF2-101 | Transactions Time to Live | HI2-38 | | Prevent replay of rejected transactions | Iroha should must provide the possibility to explicitly state time-to-live (TTL) for each transaction, so the clients will have control over the time interval in which transactions should be confirmed and put into the block store. |
|
| 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 | ADR/RFC | Brief description | Notes |
|---|
| IF2-200 | World State View |
| |
| Iroha should must have an in-memory representation of the World State View for optimization of access and change time. | In-memory, read fast data representation of the current World's State. |
| IF2-201 | Kura | HI2-1 HI2-17 HI2-18 HI2-5 | |
| Iroha should must 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. | Kura is a decorator on top of Disk Block Storage and provides validation and World State View synchronization functionality. |
| IF2-202 | Blocks Synchronization | HI2-2 HI2-43 | | Block Synchronization | Iroha should must perform seamless synchronization of block storage between peers, so so new peers or lagging ones will quickly synchronize their state with the network and join the decision-making process in consensus. | //TODO Egor Ivkov please add a small note about the gossip design and concerns. |
| IF2-203 | Merkle Tree |
| | Merkle Tree | //TODO: Egor Ivkov , may I ask you to fill that? |
|
Consensus
| ID | Item | EPIC | Importance | ADR/RFC | Brief description | 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 | ADR/RFC | Brief description | Notes |
|---|
| I2-400 | Iroha Queries | HI2-31 | |
| Iroha must provide a set of queries, which will cover the acquisition of all client-related data about all existing entities. | Iroha Queries provide information about World State View based on client permissions. |
Smart Contracts
| ID | Item | EPIC | Importance | ADR/RFC | Brief description | Notes |
|---|
| IF2-500 | Iroha Special Instructions mechanism |
| |
| Iroha must provide a possibility to create various instructions to cover |
|
| 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 in Iroha implemented based on Assets and Iroha Special Instructions. |
| IF2-503 | Triggers | HI2-37 | | Permissions and Event Listeners |
| Triggers in Iroha implemented based on Assets and Iroha Special Instructions. |
| IF2-504 | Domain-Specific Language |
| | DSL 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 |
| | 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 | ADR/RFC | Brief description | Notes |
|---|
| IF2-600 | Bridge |
| | Bridges | Iroha must provide the possibility to TBD | The mechanism for communication between third-party blockchains. |
Maintenance
| ID | Item | EPIC | Importance | ADR/RFC | Brief description | Notes |
|---|
| IF2-700 | Maintenance Endpoint | HI2-26 HI2-27 HI2-46 | | 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 | ADR/RFC | Brief description | Notes |
|---|
| 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 | |
|
|
|
| IF2-803 | Web SDK | HI2-34 HI2-10 | | Web API |
|
|
Non-Functional
Security
...