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
- Users will work with provided client libraries (iOS, Android, JS).
- 3f+1 nodes are enough to tolerate f Byzantine nodes in the network.
- Iroha uses a simple data model made up of domains, peers, accounts, assets, signatories, and permissions, as shown in the figure below - all other entities are built on top of them.
Requirements
Sources
There are the following sources for all requirements:
- The main source of core structure: Iroha 2 white paper, authored by 武宮誠
- 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
| Item | EPIC | Importance | ADR/RFC | Brief description | Notes |
|---|---|---|---|---|---|
| Peer to Peer Network Library | MUST | Networking stack | Iroha should 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. | |
| Transactions Time to Live | HI2-38 | MUST | Prevent replay of rejected transactions | Iroha should 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. | |
| Multisignature Transactions | HI2-13 | MUST | 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 | NOT DEFINED | 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 | MUST | 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 | MUST | 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 | MUST | 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 | MUST | Merkle Tree |
Consensus
Queries
| Item | EPIC | Importance | ADR/RFC | Notes |
|---|---|---|---|---|
| Iroha Queries | HI2-31 | MUST | Iroha Queries provide information about World State View based on client permissions. |
Smart Contracts
| Item | EPIC | Importance | ADR/RFC | Notes |
|---|---|---|---|---|
| Iroha Special Instructions mechanism | MUST | |||
| Out of the box set of Iroha Special Instructions | MUST | Several Tiers of Iroha Special Instructions provide:
| ||
| Permissions | HI2-36 | MUST | Permissions and Event Listeners | Permissions in Iroha implemented based on Assets and Iroha Special Instructions. |
| Triggers | HI2-37 | COULD | Permissions and Event Listeners | Triggers in Iroha implemented based on Assets and Iroha Special Instructions. |
| Domain-Specific Language | COULD | DSL Structure | Custom Iroha Special Instructions and usage of the full set of Iroha Special Instructions should be easy for developers. | |
| Advanced Permissions Model | COULD | Expand Iroha Permission model | Full-fledged rights model in Iroha will greatly reduce the amount of server development for Iroha-based applications. |
Modules
| Item | EPIC | Importance | ADR/RFC | Notes |
|---|---|---|---|---|
| Bridge | MUST | Bridges | The mechanism for communication between third-party blockchains. |
Maintenance
| Item | EPIC | Importance | ADR/RFC | Notes |
|---|---|---|---|---|
| Maintenance Endpoint | MUST | Maintenance Endpoint |
Clients
| Item | EPIC | Importance | ADR/RFC | Notes |
|---|---|---|---|---|
| Rust Client Library | HI2-32 | MUST | Iroha Client encapsulates network-related functionality and provides "local" Rust Interface for:
| |
| `no-std` client | MUST | Migration from Strings | ||
| Mobile SDK | MUST | |||
| Web SDK | MUST | Web API |
Non-Functional
Security
- Support configurable crypto algorithms
- Support for server-side HSM integration
- Security and consistency improvements
- Encapsulation of crypto-related functionality
- Transport Layer Security Configuration
Target Platforms
Iroha deployment should support GNU/Linux, 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 - Error rendering macro 'jira' : null
- Service Discovery
Continuous Delivery
- Docker images publish
- Binary and documentation publish
Longevity Stand
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
Questions
Below is a list of questions to be addressed as a result of this requirements document:
| Question | Outcome |
|---|---|
Not Doing
- Genesis Block