...
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 should 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 |
|
| Transaction dependencies |
| | Transaction tags | (Proposed by Kamil') Iroha should provide a possibility to perform tag-based dependencies between transactions for making their sequence configurable by the client |
|
Blocks storage
| Item | EPIC | Importance | ADR/RFC | Brief description | Notes |
|---|
| World State View |
| |
| Iroha should 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. |
| Kura | HI2-1 HI2-17 HI2-18 HI2-5 | |
| 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. | Kura is a decorator on top of Disk Block Storage and provides validation and World State View synchronization functionality. |
| Blocks Synchronization | HI2-2 HI2-43 | | Block Synchronization | 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. |
| Merkle Tree |
| | Merkle Tree |
|
|
Consensus
Queries
| Item | EPIC | Importance | ADR/RFC | Notes |
|---|
| Iroha Queries | HI2-31 | |
| Iroha Queries provide information about World State View based on client permissions. |
Smart Contracts
| Item | EPIC | Importance | ADR/RFC | Notes |
|---|
| Iroha Special Instructions mechanism |
| |
|
|
| 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.)
|
| Permissions | HI2-36 | | Permissions and Event Listeners | Permissions in Iroha implemented based on Assets and Iroha Special Instructions. |
| Triggers | HI2-37 | | Permissions and Event Listeners | Triggers in Iroha implemented based on Assets and Iroha Special Instructions. |
| Domain-Specific Language |
| | DSL Structure | Custom Iroha Special Instructions and usage of the full set of Iroha Special Instructions should be easy for developers. |
| 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. |
...
Maintenance
...