4.1.1. Account (アカウント、口座)¶
指定された一連のアクションを実行できるIrohaエンティティ。 各アカウントは既存の ドメイン<#domain> __のいずれかに属します。
アカウントにはいくつかの role <#role> __（noneにすることができます）があります。これは権限の集合です。 付与可能なアクセス権<＃grantable-permission> __だけがアカウントに直接割り当てられます。
4.1.2. Ametsuchi¶
Irohaのストレージコンポーネント。取引ブロックと、ブロックから生成された状態を保存します。これは、「World State View <＃world-state-view>」と呼ばれます。 クライアント<#client> __がAmetsuchiと直接対話する方法はありません。
4.1.3. Asset（資産、アセット）¶
数えられる商品や価値。各アセットは、システム内の既存の ドメイン<#domain> __に関連づけられています。 たとえば、資産（アセット）は通貨単位、金の延べ棒、不動産など、さまざまな種類の単位を表すことができます。
4.1.4. Block (ブロック)¶
トランザクションデータはブロックと呼ばれるファイルに永続的に記録されます。 ブロックは、時間の経過とともに連続的・線形的に[＃f1] _に編成されてゆきます。ブロックチェーンとも呼ばれます。
ブロックは、Iroha peers <#peer> __における暗号署名で署名され、 consensus <＃conssensus> __中にいろはノード（ピア）がこのブロックに投票します。 署名可能なコンテンツはペイロードと呼ばれるため、ブロックの構造は次のようになります。
Outside payload
- デジタル署名 - ピアが作成した署名、合意形成ラウンドでブロックへの投票に使用される
Inside payload
- 高さ - ブロックチェーン内における当該ブロックまでのブロック数
- タイムスタンプ - ブロック生成時ピアによって刻まれるUNIX時間（ミリ秒単位）
- array of transactions, which successfully passed validation and consensus step
- hash of a previous block in the chain
- rejected transactions hashes — array of transaction hashes, which did not pass stateful validation step; this field is optional
4.1.5. Block Creator¶
stateless <#stateless-validation>`__検証と`stateful <#stateful-validation>`__検証が完了した一連のトランザクションからなるブロックを作成するシステムコンポーネントで、作成されたブロックはその後`コンセンサス<#consensus> __へ伝播されます。
4.1.6. Client¶
イロハを使用するアプリケーションはすべてクライアントとして扱われます。
Irohaの特徴は、クライアントがピアネットワークと通信する際に単純なクライアント/サーバー型における抽象化を使用していることです。ブロックチェーン関連システムに特有の抽象化を使用していません。 たとえばBitcoinシステムでは、クライアントもブロックを検証する必要がありますし、ハイパーレジャーFabricでは複数のピアがポーリングしてトランザクションがブロックに取り込められたのか確認する必要がありますが、Irohaではクライアントは単一のサーバーとの通信時と同様にいずれかのIrohaピアと相互通信します。
4.1.7. コマンド¶
コマンドは`state <＃world-state-view>` __を変更する意図を示します。 たとえば、Irohaで新しい role <#role> __を作成するには、 Create role <../ api / commands.html＃create-role> __コマンドを送信する必要があります。
4.1.8. コンセンサス (合意)¶
計算機科学の分野におけるコンセンサスアルゴリズムとは、分散プロセスやシステム内で特定の単一データ値に対する合意形成に使用されるプロセスを意味します。 コンセンサスアルゴリズムは、複数かつ信頼できないノードを含むネットワークにおいて信頼性を達成するように設計されています。 「合意形成問題」として知られているこの問題を解決することは、分散コンピューティングとマルチエージェントシステムにおいて重要なことです。
*アルゴリズムとしてのコンセンサス *
ネットワーク内のピア間でブロックへの合意を達成するためのアルゴリズム。 これをシステムに組み込むことにより、信頼性が向上します。
システム構成部分としてのコンセンサス
ピアネットワーク内の peer <#peer> __の間で一貫した状態 (state)を維持します。 IrohaはYet Another Consensus（YAC）という独自のコンセンサスアルゴリズムを使用しています。 このアルゴリズムの特徴は、スケーラビリティ（拡張性）、パフォーマンス（処理能力）、および Byzantine fault tolerance <https://en.wikipedia.org/wiki/Byzantine_fault_tolerance> _です。 もし欠落しているブロックがあった場合、それらは Synchronizer <#synchronizer> __経由で別のピアからダウンロードされます。 コミットされたブロックは `Ametsuchi <#ametsuchi>`ブロックストレージに格納されます。
4.1.9. ドメイン¶
accounts <#account> __と assets <#asset> __をグループ化するために、名称を与え抽象化したもの。
4.1.10. Ordering Gate (検証作業の要求経路)¶
Peer Communication Service <＃peer-communication-service> __から Ordering Service <＃ordering-service>`へ`トランザクション<#transaction> __を渡すIrohaの内部コンポーネント。 Ordering Gateは、最終的にOrdering Serviceから proposals <#proposal> __を受け取り、それらに対して`` Stateful validation <＃stateful-validation> __を行うために Simulator <#simulator> `__に送ります。
4.1.11. Ordering Service¶
stateless validation <＃stateless-validation> __を通過したものとして渡された`トランザクション<#transaction>` __ を`proposal <#proposal>` __として組み合わせる作業を担うIrohaの内部コンポーネントです。 プロポーザルの作成は、次のいずれかのイベントによって引き起こされます。
- 取引収集のための時間が制限を超えた場合。
- オーダーリングサービスが、1つのプロポーザルに許可された最大取引量を受け取った場合。
両方のパラメータ（タイムアウトとプロポーザルに付与する最大サイズ）は設定可能です（ 環境パラメータ<../guides/configuration.html＃環境固有パラメータ> _のページをご確認ください）。
両方のトリガーに共通する前提条件は、少なくとも1つのトランザクションがオーダリングサービスに到達しているということです。 それ以外の場合、プロポーザルは作成されません。
4.1.12. ピア（ネットワークノード）¶
Irohaネットワークを構成するノード。 ピアは コンセンサス<#consensus> _形成プロセスに参加しています。
4.1.13. ピア間通信サービス (PCS)¶
イロハの内部構成要素の１つ - 鳥居<#torii> __から送られてくる transaction <#transaction> __を`Ordering Gate <＃ordering-gate>`へ送信します。 PCSの主な目的は、コンセンサスの実装とそれ以外における相互通信の複雑さを隠すことです。
4.1.14. 権限 (Permission)¶
コマンドの実行権限を与えるルールで、それぞれに名称が付けられています。 Permission **は account <#account> __に直接付与することはできません。代わりに、アカウントには権限の集合体であるロール、役割が与えられています。
4.1.14.1. 付与可能な権限¶
与えられた権限だけが`account <#account>` __に与えられます。 付与することのできる権限を持つアカウントは、別のアカウントに代わって特定のアクションを実行できます。 たとえばa@domain1というアカウントがb@domain2というアカウントに対して、アセットを転送できるようにする権限をb@domain2に与えると、b@domain2はa@domain1のアセットを誰にでも転送することができます。
4.1.15. プロポーザル（新規ブロックの提案）¶
stateless validation <＃stateless-validation> __だけを通過した一連の transactions <#transaction> __
4.1.16. クエリー（問い合わせ）¶
イロハへのリクエストは、 `state <#world-state-view>`__を変更しません。 情報の照会を実行することにより、クライアントは状態に関する照会したい情報（例えば、彼の口座の残高、取引履歴など）を得ることができます。
4.1.17. Quorum¶
In the context of transactions signing, quorum number is a minimum amount of signatures required to consider a transaction signed. The default value is 1. Each account can link additional public keys and increase own quorum number.
4.1.18. 役割 (Role)¶
permissions <#permission> __(複数可) がグループ化され、役割として抽象化されたもの。
4.1.19. Signatory¶
Represents an entity that can confirm multisignature transactions for some account. It can be attached to account via AddSignatory and detached via RemoveSignatory.
4.1.21. シンクロナイザー¶
`consensus <#consensus>`__の一部です。 不足しているブロックを `peers' <#peer>`__に追加します。（他のピアからダウンロードします）
4.1.22. Torii（鳥居）¶
⛩ clients <#client> __のエントリポイント。 gRPCをトランスポート層で使用します。 Irohaと通信するには、 Commands <../ api / commands.html> __と Queries <../ api / queries.html> __の項で記述されているgRPCエンドポイントを使用するか、クライアントライブラリ <../ guides / libraries.html> `__を使用してください。
4.1.23. トランザクション¶
台帳に原子的（atomically）に適用される順序付けられた commands <#command> __です。 トランザクション内に無効なコマンドが含まれていると、検証処理中にトランザクション全体が拒否されます。
4.1.23.1. Transaction Structure¶
Payload stores all transaction fields, except signatures:
- Time of creation (unix time, in milliseconds)
- Account ID of transaction creator (username@domain)
- Quorum field (indicates required number of signatures)
- Repeated commands which are described in details in commands section
- Batch meta information (optional part). See Batch of Transactions for details
Signatures contain one or many signatures (ed25519 public key + signature)
4.1.23.1.1. Reduced Transaction Hash¶
Reduced hash is calculated over transaction payload excluding batch meta information. Used in Batch of Transactions.
4.1.23.2. Transaction Statuses¶
Hyperledger Iroha supports both push and pull interaction mode with a client. A client that uses pull mode requests status updates about transactions from Iroha peer by sending transaction hashes and awaiting a response. In contrary push interaction is done over the listening of an event stream for each transaction. In any of these modes, the set of transaction statuses is the same:
4.1.23.2.1. Transaction Status Set¶
- NOT_RECEIVED: requested peer does not have this transaction.
- ENOUGH_SIGNATURES_COLLECTED: this is a multisignature transaction which has enough signatures and is going to be validated by the peer.
- MST_PENDING: this transaction is a multisignature transaction which has to be signed by more keys (as requested in quorum field).
- MST_EXPIRED: this transaction is a multisignature transaction which is no longer valid and is going to be deleted by this peer.
- STATELESS_VALIDATION_FAILED: the transaction was formed with some fields, not meeting stateless validation constraints. This status is returned to a client, who formed transaction, right after the transaction was sent. It would also return the reason — what rule was violated.
- STATELESS_VALIDATION_SUCCESS: the transaction has successfully passed stateless validation. This status is returned to a client, who formed transaction, right after the transaction was sent.
- STATEFUL_VALIDATION_FAILED: the transaction has commands, which violate validation rules, checking state of the chain (e.g. asset balance, account permissions, etc.). It would also return the reason — what rule was violated.
- STATEFUL_VALIDATION_SUCCESS: the transaction has successfully passed stateful validation.
- COMMITTED: the transaction is the part of a block, which gained enough votes and is in the block store at the moment.
- REJECTED: this exact transaction was rejected by the peer during stateful validation step in previous consensus rounds. Rejected transactions' hashes are stored in block store. This is required in order to prevent replay attacks.
4.1.23.2.2. Pending Transactions¶
Any transaction that has lesser signatures at the moment than quorum of transaction creator account is considered as pending. Pending transaction will be submitted for stateful validation as soon as multisignature mechanism will collect required amount of signatures for quorum.
Transaction that already has quorum of signatures can also be considered as pending in cases when the transaction is a part of batch of transactions and there is a not fully signed transaction.
4.1.24. Batch of Transactions¶
Transactions batch is a feature that allows sending several transactions to Iroha at once preserving their order.
Each transaction within a batch includes batch meta information. Batch meta contains batch type identifier (atomic or ordered) and a list of reduced hashes of all transactions within a batch. The order of hashes prescribes transactions sequence.
Batch can contain transactions created by different accounts. Any transaction within a batch can require single or multiple signatures (depends on quorum set for an account of transaction creator). At least one transaction inside a batch should have at least one signature to let the batch pass stateless validation.
4.1.24.1. Atomic Batch¶
All the transactions within an atomic batch should pass stateful validation for the batch to be applied to a ledger.
4.1.24.2. Ordered Batch¶
Ordered batch preserves only the sequence of transactions applying to a ledger. All the transactions that able to pass stateful validation within a batch will be applied to a ledger. Validation failure of one transaction would NOT directly imply the failure of the whole batch.
4.1.25. Multisignature Transactions¶
A transaction which has the quorum greater than one is considered as multisignature (also called mst). To achieve stateful validity the confirmation is required by the signatories of the creator account. These participants need to send the same transaction with their signature.
4.1.26. 検証作業（Validator）¶
検証にはステートレスとステートフルの2種類があります。
4.1.26.1. ステートレス検証 (Sateless Validation)¶
Torii <#torii> __で実行されます。 電子署名を含むオブジェクトが正しく構成されているか否かチェックします。
4.1.26.2. ステートフル検証 (Sateful Validation)¶
Verified Proposal Creator<#verified-proposal-creator> __で実行されます。 World State View <＃world-state-view> __に対して検証が行われます。
4.1.27. Verified Proposal Creator¶
受信された`proposal <#proposal>` __に格納されている`トランザクション<#transaction>` __に対してステートフル検証<#stateful-validation> _を実行するIrohaの内部コンポーネントです。 ステートフル検証を通過したトランザクションをもとに、検証済みプロポーザル（ブロックの提案）**が作成され、 `Block Creator <＃block-creator> __に渡されます。 ステートフル検証をパスしなかったトランザクションはすべて破棄され、それらはプロポーザルには含まれません。
4.1.28. World State View¶
WSVは現在のシステム状態を反映したスナップショットと捉えることができます。 たとえば、WSVには現在account <#account> __が持っている`assets <#asset>` __の量に関する情報が保持されていますが、transaction <#transaction> __ フローに関する履歴情報は記録されていません。
| [1] | https://en.bitcoin.it/wiki/Block |