This page provides definitions for some of the most commonly used terms.

The following terms are used in the product and the documentation:

Anchor Peer

 Click here to expand...

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.


 Click here to expand...

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.


 Click here to expand...

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.

Blockchain Network

 Click here to expand...

In Gospel, the Blockchain network is a private permissioned immutable ledger of encrypted data distributed across multiple nodes. 

Certificate Authority

 Click here to expand...

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.


 Click here to expand...

Root Certificate

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).

Intermediate Certificate

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.


 Click here to expand...

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. 


 Click here to expand...
Consensus is the term used to describe the process used by the orderers in your Gospel network when deciding if a set of transactions can be cut into a block.


 Click here to expand...

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.

Encryption type
BlockThe field is encrypted at block level using AESNone
ExternallyAn external system has encrypted this fieldNo use of matchers. Cannot display in UI. Cannot be used for relation.
Externally with hashAn 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.
FieldA field key has been used to encrypt the data, managed by Gospel. No use of matchers. Cannot be used for relation.
Field with hashA 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 timeA 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.

Endorsement policy

 Click here to expand...

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.


 Click here to expand...

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.

Genesis Block

 Click here to expand...

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. 


 Click here to expand...

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. 


 Click here to expand...

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.  


 Click here to expand...

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.


 Click here to expand...

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.


 Click here to expand...

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.


 Click here to expand...

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

 Click here to expand...

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.

Record Definition

 Click here to expand...

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.


 Click here to expand...

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.


 Click here to expand...

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.


 Click here to expand...

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. 


 Click here to expand...

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. 


 Click here to expand...

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.