Here you can find definitions of all Iroha-related entities.
- Byzantine fault-tolerance (BFT)
- Iroha Components
- Iroha Modules
- Iroha Special Instructions (ISI)
- Iroha Query
- View change
- World state view (WSV)
Blockchain ledgers are digital record-keeping systems that use blockchain technology to keep financial records. These are named after old-fashioned books that were used for financial records such as prices, news, and transaction information.
During medieval times, ledger books were open for public viewing and accuracy verification. This idea is reflected in the blockchain-based systems that can check the stored data for validity.
In the context of blockchains, an asset is the representation of a valuable object on the blockchain.
Additional information on assets is available here.
Such assets can be easily swapped for other assets of the same type because they are interchangeable.
As an example, all units of the same currency are equal in their value and can be used to purchase goods. Typically, fungible assets are identical in appearance, aside from the wear of banknotes and coins.
Non-fungible assets are unique and valuable due to their specific characteristics and rarity; their value cannot be compared to other assets.
- A painting's value can vary based on the artist, the time period it was painted, and the public's interest in it.
- Two houses on the same street may have differing levels of maintenance.
- Jewellery manufacturers typically offer a range of different designs.
An asset is mintable if more of the same type can be issued.
If the initial amount of an asset is specified once and doesn't change, it is considered non-mintable.
The Genesis block sets this information for the Iroha configuration.
Byzantine fault-tolerance (BFT)
The property of being able to properly function with a network containing a certain percentage of malicious actors. Iroha is capable of functioning with up to 33% malicious actors in its peer-to-peer network.
Rust modules containing Iroha functionality.
The Iroha module responsible for consensus.
Module with the incoming request handling logic for the peer. It is used to receive, accept and route incoming instructions, and HTTP queries, as well as run-time configuration updates.
Persistence-related logic. It handles storing the blocks, log rotation, block storage folder rotation, etc.
Kagami(Teacher and Exemplar and/or looking glass)
Generator for commonly used data. It can generate cryptographic key pairs, genesis blocks, documentation, etc.
Merkle tree (hash tree)
A data structure used to validate and verify the state at each block height. Iroha's current implementation is a binary tree. See Wikipedia for more details.
Smart contracts are blockchain-based programs that run when a specific set of conditions is met. In Iroha smart contracts are implemented using core Iroha special instructions.
An event type that allows invoking an Iroha special instruction at specific block commit, time (with some caveats), etc. More on triggers here.
Each request is labelled with the API version to which it belongs. It allows a combination of different binary versions of Iroha client/peer software to interoperate, which in turn allows software upgrades in the Iroha network.
Hijiri (peer reputation system)
Iroha's reputation system. It allows prioritising communication with peers that have a good track-record, and reducing the harm that can be caused by malicious peers.
Third party extensions to Iroha that provide custom functionality.
Iroha Special Instructions (ISI)
A library of smart contracts provided with Iroha. These can be invoked via either transactions or registered event listeners. More on ISI here.
Utility Iroha Special Instructions
This set of isi contains logical instructions like
If, I/O related like
Notify and compositions like
Sequence. They are mostly used by custom instructions.
Core Iroha Special Instructions
Special instructions provided with every Iroha deployment. These include some domain-specific as well as utility instructions.
Domain-specific Iroha Special Instructions
Instructions related to domain-specific activities: assets, accounts, domains, peer management). These provide the tools necessary to make changes to the World State View in a secure and safe manner.
Custom Iroha Special Instruction
Instructions provided in Iroha Modules, by clients or 3rd parties. These can only be built using the Core Instructions. Forking and modifying the Iroha source code is not recommended, as special instructions not agreed-upon by peers in an Iroha deployment will be treated as faults, thus peers running a modified instance will have their access revoked.
A request to read the World State View without modifying said view. More on queries here.
A process that takes place in case of a failed attempt at consensus. Usually this entails the election of a new Leader.
World state view (WSV)
In-memory representation of the current blockchain state. This includes all currently loaded blocks, with all of their contents, as well as peers elected for the current epoch.
In an iroha network, a peer is selected randomly and granted the special privilege of forming the next block. This privilege can be revoked in networks that achieve Byzantine fault-torelance via view change.