This page provides definitions for some of the most commonly used terms.
The following terms are used in the product and the documentation:
A peer node on a channel that all other peers can discover and communicate with. Each Member on a channel has an anchor peer (or multiple anchor peers to prevent single point of failure), allowing for peers belonging to different Members to discover all existing peers on a channel.
The backend is a middleware component within Gospel. It is the endpoint for API connections and its purpose is to send transactions to read/write data through the Gospel process on behalf of an authenticated user.
A block is a collection of transactions, each of which represents a read/write/other notable event within the system. Data contained within them is immutable, linking blocks via hashes makes up the basis of a blockchain.
In Gospel, the Blockchain network is a private permissioned immutable ledger of encrypted data distributed across multiple nodes.
A Certificate Authority (CA) is an entity that issues digital certificates that attests the ownership of a public key. Gospel uses a digital certificate to verify the authenticity of the user (verify the user is who they claim to be) and authorises access to the system (verifies the role and permissions). It also enables you to manage, renew, and revoke keys and certificates.
A root certificate is a public key certificate that identifies a root certificate authority (CA). Root certificates are self-signed and form the basis of an X.509-based public key infrastructure (PKI).
An intermediate certificate is a subordinate certificate issued by the trusted root specifically to issue end-entity server certificates. The result is a certificate chain that begins at the trusted root CA, through the intermediate and ending with the SSL certificate issued to the user.
Chaincode is the software program containing the business logic which determines the rules governing who can do what, how and where on your Gospel network.
All data in Gospel is encrypted at rest using modern, secure AES technology. Sometimes, however, it is desirable to provide a further layer of security that cannot be decrypted without a fully validated transaction (ie without the consent of the network as a whole) or to mark data as externally encrypted so it is not displayed in the UI. Restrictions apply to how granularly encrypted fields can be used for other purposes as the Gospel engine cannot understand the data contained therein so this is generally best kept for the most sensitive data such as PII.
|Block||The field is encrypted at block level using AES||None|
|Externally||An external system has encrypted this field||No use of matchers. Cannot display in UI. Cannot be used for relation.|
|Externally with hash||An external system has encrypted this field and a hash of the underlying data (potentially consistently salted) has been stored with it.||Only equality matchers can be used. Only exact match search is possible. Cannot display in UI. Cannot be used for relation.|
|Field||A field key has been used to encrypt the data, managed by Gospel.||No use of matchers. Cannot be used for relation.|
|Field with hash||A field key has been used to encrypt the data, managed by Gospel and a salted consistently hash of the underlying data has been stored with it.||Only equality matchers can be used. Only exact match search is possible.|
|One time||A unique key has been used to encrypt the data, managed by Gospel. This key can be deleted rendering the data irretrievable as it is only used once.||No use of matchers. Cannot be used for relation.|
The endorsement policy is a set of rules that governs the endorsement of transactions bound for the network. For example, it may be specified that a certain number or all endorsing peers must endorse a transaction before it is allowed to be processed.
An Endorser is a Peer in the network that has been designated as one which is required to be a part of the transaction endorsement process.
The genesis block begins the blockchain and controls who can join the chain without being asked any questions. It also defines some configuration information for the blockchain such as the ordering mode.
The Keystore is a required component of Gospel and is part of the secure process to enforce consensus on reads. This component runs outside of a LedgerNode and is deployed for each multi-tenant namespace. It is a lightweight Go application that runs on a VM or Kubernetes Pod.
A LedgerNode is a Kubernetes deployment consisting of multiple containers that communicate with each other. A LedgerNode typically contains a Peer, a CA and an Orderer. Gospel is deployed by configuring a least 3 LedgerNodes in your Azure, GCP or AWS service.
In Gospel, a namespace refers to a Kubernetes deployment controlled by a single entity which has its data secured by digital certificates signed by the Gospel root CA for their domain of control.
In Gospel, the network is a shared store of enterprise information spread amongst a number of entities used in the form of a graph database. Gospel is deployed by configuring a least 3 LedgerNodes in your Azure, GCP or AWS service.
The Orderer ensures that transactions are processed in the same sequence to maintain the integrity of the network. In other words, the Orderer outputs the same messages to all connected peers in the same logical order.
Peers are the core part of Gospel that, together with the Orderer, form the private permissioned blockchain. The peers participate actively in the blockchain to create consensus on transactions. They store data (blockchain) and the data access rules (chaincode) in Gospel.
Private Permissioned Network
In Gospel a private permissioned network is one where multiple parties have agreed to share data in a Gospel network. All parties agree in advance who can join this network and what data can be shared with whom.
Used to define the schema for your Gospel instance, something like a table in a traditional RDBMS. Data is stored in the records, which are composed of fields. You can define the fields when creating/editing a record definition.
Records are the fundamental unit of data storage. Records are composed of fields that are defined in the record definition. The data provided in these fields are stored in records.
A transaction is an "event" that has occurred within the system, this could be a user reading a record, editing a record, logging in etc - If you replay all the events that have happened, then you can build the world state.
A Trigger can be defined as a type of action that automatically executes when an event occurs in the Gospel platform. They have the ability to take actions within the ledger based on any data the defining user can see.
Views in Gospel are similar to SQL views. This feature enables you to create a view by combining data that exists in one or more record types. Since the data in the view is dynamically generated from the two existing records, they are read-only.
A Watcher in Gospel is a process outside of the ledger that takes an action when it sees something happen in the chain. The WatcherSubscriber (an external Gospel application) receives information from the Watcher regarding changes in records, and then execute the specified actions for the matched conditions.