4.1.1. Account¶
일련의 행동을 수행할 수 있는 Iroha의 객체 입니다. 각 계정은 하나의 `도메인 <#domain>`__에 속해 있습니다.
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의 데이터 저장을 담당하는 컴포넌트로 블록의 저장 및 블록에 의해 생성된 상태 - 또는 World State View -의 저장을 담당합니다. 클라이언트 가 직접 Ametsuchi와 직접 상호작용할 수 없습니다.
4.1.3. 에셋(Asset)¶
셀 수 있는 모든 상품 또는 값을 의미합니다. 각 에셋은 하나의 `도메인 <#domain>`__에 속해 있습니다. 예를 들어, 통화 단위나 골드바, 부동산 단위 처럼 에셋은 어떠한 단위로든지 표현될 수 있습니다.
4.1.4. 블록(Block)¶
트랜젝션 데이터는 블록이라고 불리는 파일에 영구적으로 기록됩니다. 블록은 시간에 따라 선형적인 순서를 가지도록 구성되어 있습니다.(이런 구조때문에 블록체인이라 불리기도 합니다.) [1]
블록은 Iroha 피어 <#peer>`__의 암호학적인 서명(signature)들로 서명되어 있습니다. 이 서명들은 `합의 과정에서 블록에 대해 투표(vote)할 때 사용됩니다. 서명가능한 컨텐츠는 payload로 불립니다. 블록의 구조는 아래와 같습니다:
Outside payload
- 서명(signatures) — 합의(Consensus) 중에 블록에 투표(vote)한 피어들의 서명
Inside payload
- 높이(height) — 현재 블록까지의 블록의 수
- 타임스탬프(timestamp) — 피어에 의해 블록이 생성된 유닉스 시간(밀리세컨즈 단위)
- 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)¶
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)¶
Iroha를 사용하는 모든 형태의 어플리케이션을 클라이언트로 취급합니다.
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)¶
커맨드는 `상태 <#world-state-view>`__를 바꾸기 위해 사용됩니다. 예를 들어 Iroha에 새로운 `역할 <#role>`__을 생성하기 위해서는 `역할 생성하기 <../api/commands.html#create-role>`__커맨드를 사용해야 합니다.
4.1.8. 합의(Consensus)¶
합의 알고리즘은 다수의 프로세스나 시스템에 분산되어 있는 하나의 데이터에 대해 합의를 이루는 컴퓨터 과학의 한 방법입니다. 합의 알고리즘은 다수의 신뢰할 수 없는 노드가 포함된 네트워크의 신뢰성(Reliability)을 이루기 위해 디자인 되었습니다. 합의 문제로 불리기도 하는 이러한 문제를 해결하는 것은 분산 컴퓨팅과 multi-agent 시스템에서 중요한 문제입니다.
알고리즘으로서의 합의
네트워크 피어들이 가지고 있는 하나의 블록에 대해 합의를 이루게 하는 알고리즘입니다. 이 알고리즘을 통해 네트워크 신뢰성이 증가합니다.
컴포넌트로서의 합의
피어 들 간의 일정한 상태를 보존합니다. Iroha는 Yet Another Consensus(YAC)라는 자체적인 합의 알고리즘을 사용하고 있습니다. 이 알고리즘의 특징은 scalability와 퍼포먼스, 비잔틴 장애 허용(Byzantine fault tolerance). 만약 빠진(missing) 블록이 있는 경우 Synchronizer <#synchronizer>`__를 통해 다른 피어로부터 빠진 블록을 다운로드 받습니다. 커밋된 블록은 `Ametsuchi 블록 저장소에 저장됩니다.
4.1.10. Ordering Gate¶
Iroha의 내부 컴포넌트로 Peer Communication Service <#peer-communication-service>`__로부터 `트랜젝션 을 `Ordering Service <#ordering-service>`__로 전달합니다.
4.1.11. Ordering Service¶
Iroha의 내부 컴포넌트로 `stateless validation <#stateless-validation>`__을 통과한 여러 `트랜젝션 <#transaction>`__을 합쳐 `proposal <#proposal>`__로 만듭니다. Proposal 생성은 아래 이벤트 중 하나로 인해 일어나게 됩니다.
- 트랜젝션을 모으는(transaction collection) 시간 제한이 지난 경우
- Ordering service가 하나의 Proposal에 포함될 수 있는 트랜젝션 수보다 더 많은 트랜젝션을 받은 경우
두 파라미터 (시간초과와 Proposal의 최대 트랜젝션의 수)는 설정 가능합니다.(environment-specific parameters 페이지를 확인하세요.)
위의 두 가지 경우 중 하나라도 발생하기 위해서는 적어도 하나의 트랜젝션이 Ordering Service에 도달해야 합니다. 그렇지 않으면 proposal은 생성되지 않습니다.
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.
4.1.14.1. 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.
4.1.16. 쿼리¶
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.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)¶
A named abstraction that holds a set of permissions.
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.20. Simulator¶
4.1.21. Synchronizer¶
Is a part of consensus. Adds missing blocks to peers' chains (downloads them from other peers).
4.1.22. 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.23. 트랜젝션¶
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.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)¶
stateless 검증과 stateful 검증, 총 2 종류의 검증이 있습니다.
4.1.27. 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.28. 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.
| [1] | https://en.bitcoin.it/wiki/Block |