This article is for open source enthusiasts with an interest in blockchain technology, and continues with the series on blockchain frameworks in Project Hyperledger. So let’s look at Hyperledger Iroha, see what makes it unique and learn how to get started with this framework.
Hyperledger Iroha is a blockchain framework, and one of the Hyperledger projects hosted by The Linux Foundation. Initially contributed by Soramitsu, Hitachi, NTT Dat and Colu, it is designed to be simple and easy to incorporate into infrastructure projects requiring distributed ledger technology. Hyperledger Iroha features a simple, modern construction, has a domain-driven C++ design, with an emphasis on mobile application development, and it comes with the YAC consensus algorithm. This framework is a blockchain platform implementation, designed to be easily incorporated into other distributed ledger technologies. Hyperledger Iroha is designed to compile a library of reusable modular components that enhance existing distributed ledger frameworks.
The goals of Hyperledger Iroha
The team behind Hyperledger Iroha set out to achieve the following three goals:
- Provide an environment for C++ developers to contribute to Hyperledger.
- Provide infrastructure for mobile and Web application support.
- Provide a framework to introduce APIs and a new consensus algorithm that can potentially be incorporated into other frameworks in the future.
The architecture
The core architecture of Hyperledger Iroha was inspired by Hyperledger Fabric. The creators of Hyperledger Iroha have emphasised the importance of this framework in fulfilling the need for user-friendly interfaces. In doing so, they’ve created a framework with many defining features, and have achieved their stated goals of a simple construction, a modern C++ design with an emphasis on mobile application development, and a new chain-based Byzantine fault-tolerant consensus algorithm called Sumeragi. The most defining characteristic of Hyperledger Iroha is its ability to be freely interoperable with other Hyperledger projects. The open source libraries for iOS, Android and JavaScript allow developers to conveniently create functions for performing common operations.
Figure 1 shows a layered architectural view of the different components that make up Hyperledger Iroha. The four layers are: API, Peer Interaction, Chain Business Logic and Storage.
Here is a brief description of the components of Hyperledger Iroha.
Model classes are system entities.
Torii (gate) provides the input and output interfaces for clients. It is a single gRPC server that is used by clients to interact with peers through the network. The client’s RPC call is non-blocking, making Torii an asynchronous server. Both commands (transactions) and queries (read access) are performed through this interface.
Network encompasses interaction with the network of peers.
Consensus is in charge of peers agreeing on chain content in the network. The consensus mechanism used by Iroha is YAC (Yet Another Consensus), which is a practical Byzantine fault-tolerant algorithm based on voting for block hash.
Simulator generates a temporary snapshot of storage to validate transactions by executing them against this snapshot and forming a verified proposal, which consists only of valid transactions.
Validator classes check the business rules and validity (correct format) of transactions or queries.
There are two distinct types of validation that occur in Hyperledger Iroha:
- Stateless validation is a quicker form of validation, and it performs schema and signature checks of the transaction.
- Stateful validation is slower and checks the permissions and the current world state view (which is the latest and most actual state of the chain) to see if desired business rules and policies are possible — for example, to check if an account has enough funds to transfer.
Synchroniser helps to synchronise new peers in the system or temporarily disconnect peers.
Ametsuchi is the ledger block storage which consists of a block index, block store, and a world state view component.
Key participants in the network
There are three main participants in a Hyperledger Iroha network.
Clients are able to:
- Query data that they have access/permission to;
- Perform a state-changing action or ‘transaction’, which consists of atomic operations, called ‘commands’.
Peers maintain the current state and their own copy of the shared ledger. A peer is a single entity in the network, and has an address, identity and trust.
The ordering service orders transactions into a known order. There are a few options for the algorithm used by the ordering service.
Transaction flow
Step 1: A client creates and sends a transaction to the Torii gate, which routes the transaction to a peer that is responsible for performing stateless validation.
Step 2: After the peer performs stateless validation, the transaction is first sent to the ordering gate, which is responsible for choosing the right strategy for connection to the ordering service.
Step 3: The ordering service puts transactions into order and forwards them to peers in the consensus network in the form of proposals. A proposal is an unsigned block shared by the ordering service that contains a batch of ordered transactions. Proposals are only forwarded when the ordering service has accumulated enough transactions, or a certain amount of time has elapsed since the last proposal. This prevents the ordering service from sending empty proposals.
Step 4: Each peer verifies the proposal’s contents (stateful validation) in the simulator, and creates a block that consists only of verified transactions. This block is then sent to the consensus gate, which performs YAC consensus logic.
Step 5: An ordered list of peers is determined, and a leader is elected based on the YAC consensus logic. Each peer casts a vote by signing and sending its proposed block to the leader.
Step 6: If the leader receives enough signed proposed blocks (i.e., more than two-thirds of the peers), then it starts to send a commit message, indicating that this block should be applied to the chain of each peer participating in the consensus. Once the commit message has been sent, the proposed block becomes the next block in the chain of every peer, via the synchroniser.
The YA Consensus algorithm
Hyperledger Iroha currently implements the YAC consensus algorithm, which is based on voting for block hash. The YAC performs two functions: ordering and consensus.
‘Ordering’ is responsible for ordering all transactions, packaging them into proposals, and sending them to peers in the network. The ordering service is an endpoint for setting an order of transactions and their broadcast (in a form of proposal). Ordering is not responsible for performing stateful validation of transactions.
‘Consensus’ involves taking blocks after they have been validated, collaborating with other blocks to decide on a commit, and propagating commits between peers. ‘Consensus’ is responsible for an agreement on blocks based on the same proposal.
‘Validation’ is an important part of the transaction flow; however, it is separate from the consensus process.
Note: Currently, the ordering service is a single point of failure that does the ordering and, therefore, Hyperledger Iroha is neither crash fault-tolerant, nor Byzantine fault-tolerant.
Hyperledger Iroha’s mobile libraries
A major goal for the creators of Hyperledger Iroha is to develop a distributed ledger system that can be easily used by applications. In order to accomplish this, Hyperledger Iroha offers open source software libraries for iOS, Android, and JavaScript. These libraries allow for simple compatibility with not only Hyperledger Iroha, but also, potentially, with other networks through flexible API functions. These libraries are all open source, and available on GitHub.
An overview of the community
Hyperledger Iroha is an open source project for which ideas and code can be publicly discussed, created and reviewed. There are many ways to get involved with the Hyperledger Iroha community, one of which is through GitHub.
