| Chain Member | Entities that do not participate in the validation process of a blockchain network, but help to maintain the integrity of a network. Unlike Chain transactors, chain members maintain a local copy of the ledger. |
| Chain Transactor | Entities that have permission to create transactions and query network data. |
| Chain Validator | Entities that own a stake of a chain network. Each chain validator has a voice in deciding whether a transaction is valid, therefore chain validators can interrogate all transactions sent to their chain. |
| Chain Auditor | Entities with the permission to interrogate transactions. |
| Solution User |
End users are agnostic about the details of chain networks, they typically initiate transactions on a chain network through applications made available by solutions providers.
Roles: None |
| Solution Provider |
Organizations that develop mobile and/or browser based applications for end (solution) users to access chain networks. Some application owners may also be network owners.
Roles: Chain Transactor |
| Network Proprietor |
Proprietor(s) setup and define the purpose of a chain network. They are the stakeholders of a network.
Roles: Chain Transactor, Chain Validator |
| Network Owner |
Owners are stakeholders of a network that can validate transactions. After a network is first launched, its proprietor (who then becomes an owner) will invite business partners to co-own the network (by assigning them validating nodes). Any new owner added to a network must be approved by its existing owners.
Roles: Chain Transactor, Chain Validator |
| Network Member |
Members are participants of a blockchain network that cannot validate transactions but has the right to add users to the network.
Roles: Chain Transactor, Chain Member |
| Network Users |
End users of a network are also solution users. Unlike network owners and members, users do not own nodes. They transact with the network through an entry point offered by a member or an owner node.
Roles: Chain Transactor |
| Network Auditors |
Individuals or organizations with the permission to interrogate transactions.
Roles: Chain Auditor |
| Industry Network | A chain network that services solutions built for a particular industry. |
| Regional Industry Network | A chain network that services applications built for a particular industry and region. |
| Application Network | A chain network that only services a single solution. |
| Main Chain | A business network; each main chain operates one or multiple applications/solutions validated by the same group of organizations. |
| Confidential Chain | A special purpose chain created to run confidential business logic that is only accessible by contract stakeholders. |
| Owner Registration | The process of registering and inviting new owner(s) to a blockchain network. Approval from existing network owners is required when adding or deleting a participant with ownership right |
| Member Registration | The process of registering and inviting new network members to a blockchain network. |
| User Registration | The process of registering new users to a blockchain network. Both members and owners can register users on their own behalf as long as they follow the policy of their network. |
| Deployment Transaction | Transactions that deploy a new chaincode to a chain. |
| Invocation Transaction | Transactions that invoke a function on a chaincode. |
| Public Transaction | A transaction with its payload in the open. Anyone with access to a chain network can interrogate the details of public transactions. |
| Confidential Transaction | A transaction with its payload cryptographically hidden such that no one besides the stakeholders of a transaction can interrogate its content. |
| Confidential Chaincode Transaction | A transaction with its payload encrypted such that only validators can decrypt them. Chaincode confidentiality is determined during deploy time. If a chaincode is deployed as a confidential chaincode, then the payload of all subsequent invocation transactions to that chaincode will be encrypted. |
| Inter-Network Transaction | Transactions between two business networks (main chains). |
| Inter-Chain Transaction | Transactions between confidential chains and main chains. Chaincodes in a confidential chain can trigger transactions on one or multiple main chain(s). |
| Application Backend |
Purpose: Backend application service that supports associated mobile and/or browser based applications.
Key Roles: 1) Manages end users and registers them with the membership service 2) Initiates transactions requests, and sends the requests to a node Owned by: Solution Provider, Network Proprietor |
| Non Validating Node (Peer) |
Purpose: Constructs transactions and forwards them to validating nodes. Peer nodes keep a copy of all transaction records so that solution providers can query them locally.
Key Roles: 1) Manages and maintains user certificates issued by the membership service 2) Constructs transactions and forwards them to validating nodes 3) Maintains a local copy of the ledger, and allows application owners to query information locally. Owned by: Solution Provider, Network Auditor |
| Validating Node (Peer) |
Purpose: Creates and validates transactions, and maintains the state of chaincodes Key Roles: 1) Manages and maintains user certificates issued by membership service 2) Creates transactions 3) Executes and validates transactions with other validating nodes on the network 4) Maintains a local copy of ledger 5) Participates in consensus and updates ledger Owned by: Network Proprietor, Solution Provider (if they belong to the same entity) |
| Membership Service |
Purpose: Issues and manages the identity of end users and organizations Key Roles: 1) Issues enrollment certificate to each end user and organization 2) Issues transaction certificates associated to each end user and organization 3) Issues TLS certificates for secured communication between Hyperledger fabric entities 4) Issues chain specific keys Owned by: Third party service provider |
| Registration Authority | Assigns registration username & registration password pairs to network participants. This username/password pair will be used to acquire enrollment certificate from ECA. |
| Enrollment Certificate Authority (ECA) | Issues enrollment certificates (ECert) to network participants that have already registered with a membership service. ECerts are long term certificates used to identify individual entities participating in one or more networks. |
| Transaction Certificate Authority (TCA) | Issues transaction certificates (TCerts) to ECert owners. An infinite number of TCerts can be derived from each ECert. TCerts are used by network participants to send transactions. Depending on the level of security requirements, network participants may choose to use a new TCert for every transaction. |
| TLS-Certificate Authority (TLS-CA) | Issues TLS certificates to systems that transmit messages in a chain network. TLS certificates are used to secure the communication channel between systems. |
| Public Chaincode | Chaincodes deployed by public transactions, these chaincodes can be invoked by any member of the network. |
| Confidential Chaincode | Chaincodes deployed by confidential transactions, these chaincodes can only be invoked by validating members (Chain validators) of the network. |
| Access Controlled Chaincode | Chaincodes deployed by confidential transactions that also embed the tokens of approved invokers. These invokers are also allowed to invoke confidential chaincodes even though they are not validators. |
| Chaincode-State | HPL provides state support; Chaincodes access internal state storage through state APIs. States are created and updated by transactions calling chaincode functions with state accessing logic. |
| Transaction List | All processed transactions are kept in the ledger in their original form (with payload encrypted for confidential transactions), so that network participants can interrogate past transactions to which they have access permissions. |
| Ledger Hash | A hash that captures the present snapshot of the ledger. It is a product of all validated transactions processed by the network since the genesis transaction. |
| DevOps Service | The frontal module on a node that provides APIs for clients to interact with their node and chain network. This module is also responsible to construct transactions, and work with the membership service component to receive and store all types of certificates and encryption keys in its storage. |
| Node Service | The main module on a node that is responsible to process transactions, deploy and execute chaincodes, maintain ledger data, and trigger the consensus process. |
| Consensus | The default consensus algorithm of Hyperledger fabric is called Sieve. It is a new algorithm, enhancing the “classic” PBFT mechanism in that it allows validating nodes to do a best effort in identifying non-deterministic transactions. |