2.2. What’s inside Iroha?¶
HL Iroha network consists of several essential components that provide the communication between the nodes. You can learn about them below.
2.2.1. Torii¶
⛩
Entry point for clients. Uses gRPC as a transport. In order to interact with Iroha anyone can use gRPC endpoints, described in Commands and Queries sections, or use client libraries.
2.2.2. MST Processor¶
Multisignature Transactions Processor
It is an internal gRPC service that sends and receives messages from other peers through Gossip protocol. Its mission is to send out multisignature transactions that have not received enough signatures to reach the quorum until it is reached.
2.2.3. Peer Communication Service¶
Internal component of Iroha - an intermediary that transmits transaction from Torii through MstProcessor to Ordering Gate. The main goal of PCS is to hide the complexity of interaction with consensus implementation.
2.2.4. Ordering Gate¶
It is an internal Iroha component (gRPC client) that relays transactions from Peer Communication Service to Ordering Service. Ordering Gate recieves proposals (potential blocks in the chain) from Ordering Service and sends them to Simulator for stateful validation. It also requests proposal from the Ordering Service based on the consensus round.
2.2.5. Ordering Service¶
Internal Iroha component (gRPC server) that receives messages from other peers and combines several transactions that have been passed stateless validation into a proposal. Each node has its own ordering service. Proposal creation could be triggered by one of the following events:
- Time limit dedicated to transactions collection has expired.
- Ordering service has received the maximum amount of transactions allowed for a single proposal.
Both parameters (timeout and maximum size of proposal) are configurable (check environment-specific parameters page).
A common precondition for both triggers is that at least one transaction should reach the ordering service. Otherwise, no proposal will be formed.
Ordering service also performs preliminary validation of the proposals (e.g. clearing out statelessly rejected transactions from the proposal).
2.2.6. Verified Proposal Creator¶
Internal Iroha component that performs stateful validation of transactions contained in received proposal from the Ordering Service. On the basis of transactions that have passed stateful validation verified proposal will be created and passed to Block Creator. All the transactions that have not passed stateful validation will be dropped and not included in a verified proposal.
2.2.7. Block Creator¶
System component that forms a block from a set of transactions that have passed stateless and stateful validation for further propagation to consensus.
Block creator, together with the Verified Proposal Creator form a component called Simulator.
2.2.8. Block Consensus (YAC)¶
Consensus, as a component
Consensus is the heart of the blockchain - it preserves a consistent state among the peers within a peer network. Iroha uses own consensus algorithm called Yet Another Consensus (aka YAC).
You can check out a video with a thorough explanation of the principles of consensus and YAC in particular here.
Distinctive features of YAC algorithm are its scalability, performance and Crash fault tolerance.
To ensure consistency in the network, if there are missing blocks, they will be downloaded from another peer via Synchronizer. Committed blocks are stored in Ametsuchi block storage.
For general definition of the consensus, please check this link.
2.2.9. Synchronizer¶
Is a part of consensus. Adds missing blocks to peers’ chains (downloads them from other peers to preserve consistency).
2.2.10. Ametsuchi Blockstore¶
Iroha storage component, which stores blocks and a state generated from blocks, called World State View. There is no way for the client to directly interact with Ametsuchi.
2.2.11. World State View¶
WSV reflects the current state of the system, can be considered as a snapshot. For example, WSV holds information about an amount of assets that an account has at the moment but does not contain any info history of transaction flow.