4.1.1. Account

An Iroha entity that is able to perform specified set of actions. Each account belongs to one of existing domains.

An account has some number of roles (can be none) — which is a collection of permissions. Only grantable permissions are assigned to an account directly.

4.1.2. Ametsuchi

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.

4.1.3. Asset

Any countable commodity or value. Each asset is related to one of existing domains. For example, an asset can represent any kind of such units - currency unit, a bar of gold, real estate unit, etc.

4.1.4. Block

Transaction data is permanently recorded in files called blocks. Blocks are organized into a linear sequence over time (also known as the block chain) [1].

Blocks are signed with the cryptographic signatures of Iroha peers, voting for this block during consensus. Signable content is called payload, so the structure of a block looks like this:

Outside payload

  • hash — SHA3-512 hash of block protobuf payload
  • signatures — signatures of peers, which voted for the block during consensus round

Inside payload

  • height — a number of blocks in the chain up to the block
  • timestamp — Unix time (in milliseconds) of block forming by a peer
  • body — transactions, which successfully passed validation and consensus step
  • transactions quantity
  • previous hash of a block

4.1.5. Block Creator

System component that forms a block from a set of transactions that have been passed stateless and stateful validation for further propagation to consensus.

4.1.6. Client

Any application that uses Iroha is treated as a client.

A distinctive feature of Iroha is that all clients are using simple client-server abstractions when they interact with a peer network: they don’t use any abstractions which are specific for blockchain-related systems. For example, in Bitcoin clients have to validate blocks, or in Fabric they need to poll several peers to make sure that a transaction was written in a block, whereas in Iroha a client interacts with any peer similarly to a single server.

4.1.7. Command

A command is an intention to change the state. For example, in order to create a new role in Iroha you have to issue Create role command.

4.1.8. Consensus

A consensus algorithm is a process in computer science used to achieve agreement on a single data value among distributed processes or systems. Consensus algorithms are designed to achieve reliability in a network involving multiple unreliable nodes. Solving that issue – known as the consensus problem – is important in distributed computing and multi-agent systems.

Consensus, as an algorithm

An algorithm to achieve agreement on a block among peers in the network. By having it in the system, reliability is increased.

Consensus, as a component

Preserves consistent state among the peers within a peer network. Iroha uses own consensus algorithm called Yet Another Consensus (aka YAC). Distinctive features of this algorithm are its scalability, performance, and Byzantine fault tolerance. If there are missing blocks, they will be downloaded from another peer via Synchronizer. Committed blocks are stored in Ametsuchi block storage.

4.1.9. Domain

A named abstraction for grouping accounts and assets.

4.1.10. Ordering Gate

Internal Iroha component that passes transactions from Peer Communication Service to Ordering Service. Ordering Gate eventually recieves proposals from Ordering Service and sends them to Simulator for stateful validation.

4.1.11. Ordering Service

Internal Iroha component that combines several transactions that have been passed stateless validation into a proposal. Proposal creation could be triggered by one of the following events:

  1. Time limit dedicated to transactions collection has expired.
  2. 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 ordering service. Otherwise, no proposal will be formed.

4.1.12. Peer

A node that is a part of Iroha network. It participates in consensus process.

4.1.13. Peer Communication Service

Internal component of Iroha - an intermediary that transmits transaction from Torii to Ordering Gate. The main goal of PCS is to hide the complexity of interaction with consensus implementation.

4.1.14. Permission

A named rule that gives the privilege to perform a command. Permission cannot be granted to an account directly, instead, an account has roles, which are the collection of permissions. Grantable Permission

Only grantable permission is given to an account directly. An account that holds grantable permission is allowed to perform some particular action on behalf of another account. For example, if the account a@domain1 gives the account b@domain2 a permission that it can transfer assets — then b@domain2 can transfer assets of a@domain1 to anyone.

4.1.15. Proposal

A set of transactions that have passed only stateless validation. Verified Proposal

A set of transactions that have been passed stateless and stateful validation, but were not committed yet.

4.1.16. Role

A named abstraction that holds a set of permissions.

4.1.17. Simulator

See Verified Proposal Creator.

4.1.18. Query

A request to Iroha that does not change the state. By performing a query, a client can get request data from the state, for example a balance of his account, a history of transactions, etc.

4.1.19. Synchronizer

Is a part of consensus. Adds missing blocks to peers’ chains (downloads them from other peers).

4.1.20. 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.

4.1.21. Transaction

An ordered set of commands, which is applied to the ledger atomically. Any nonvalid command within a transaction leads to rejection of the whole transaction during the validation process.

4.1.22. Validator

There are two kinds of validation - stateless and stateful. Stateless Validation

Performed in Torii. Checks if an object is well-formed, including the signatures. Stateful Validation

Performed in Verified Proposal Creator. Validates against World State View.

4.1.23. Verified Proposal Creator

Internal Iroha component that performs stateful validation of transactions contained in received proposal. On the basis of transactions that have been 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.

4.1.24. 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.