| 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 transaction 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 provided 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 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 logics that are only accessable by contract stakeholders. |
| 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 transaction. |
| Confidential transaction | A transaction with encrypted payload. If the transaction is a deployment transaction, then all subsequent invocation transactions calling that chaincode deployed must also be confidential. |
| 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 membership service 2) Initiates transactions requests, and sends the request 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 transactions records so that solution providers can query them locally. (Dev Team name: NVP - Non Validating Peer)
Key Roles: 1) Manages and maintains user certificates issued by 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 states 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 update 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 OBC entities 4) Issues chain specific keys Owned by: Third party service provider |
| Registration Authority | Assigns username & 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 transactions certificates (TCerts) to ECert owners. An infinite number of TCerts can be derived from each ECert. TCerts are used by network participants to transact transactions. Depending on the level of security requirement, 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 line between systems. |
| Public Chaincode | Chaincodes deployed by public transactions, these chaincodes can be invoked by any member of a network. |
| Confidential Chaincode | Chaincodes deployed by confidential transactions, these chaincodes can only be invoked by validating members (Chain validators) of a network. |
| Access Controlled Chaincode | Chaincodes deployed by confidential transactions that also embed the tokens of allowable invokers. These invokers are also allowed to invoke confidential chaincodes even though they are not validators. |
| Chaincode-State | OBC 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 that they have the access permission. |
| 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 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 consensus process. |
| Consensus | The default consensus algorithm of OBC 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. |