editEdit on GitHub

Glossary of Terms

The Exonum documentation uses some specific terms to describe key Exonum concepts. Here, these terms are condensed to a single page.


All terms here are defined with Exonum in mind. For example, Transaction describes how transactions work in Exonum; generally speaking, transaction may have a lot of other meanings (but they are not covered in this document).


Aka auditing node

A full node in the blockchain network that does not participate in creating new blocks, but rather performs continuous audit of all transactions in the network. Auditors are identified by a public key within the blockchain network. Unlike validators, adding auditors does not create an overhead in transaction latency and throughput, so there can be hundreds of auditors in the same blockchain network.


Consider an Exonum blockchain that implements public registry in a particular country. In this case, auditing nodes may belong to non-government agencies who are interested in monitoring the operation of the registry.

Authenticated Consensus

Type of consensus, in which the participants are known in advance and are authenticated, usually with the help of public-key cryptography (such as digital signatures). Exonum uses authenticated consensus algorithm slightly similar to PBFT, in order to keep the system decentralized and withstand attacks by Byzantine validators.

Binary Serialization

Serialization of data stored in the blockchain and messages into a platform-independent sequence of bytes according to the set of rules defined by the Exonum framework. Binary serialization is used in Exonum for cryptographic operations, such as computing hashes and digital signing. It is implemented both in the core and in the light client library.

The Exonum serialization format is optimized to provide almost zero-cost deserialization in low-level programming environments (such as Rust).


See Serialization for more details.


Ordered list of transactions in the blockchain, together with the authentication by at least 2/3 of the validator set, and some additional information (such as the hash of the previous block and the hash of the blockchain state after applying transactions in the block). The compact block form, in which transactions are replaced by the root of their Merkle tree, is used for communication with light clients.


A distributed ledger, which uses hash linking to achieve the immutability of the transaction log, and other cryptographic tools to improve accountability. Transactions in a blockchain are grouped in blocks to improve auditing by light clients.

Whereas the design goal of a distributed ledger is decentralized data management, one of the design goals of a blockchain is achieving accountability of the blockchain maintainers and auditability of the system by third parties (e.g., internal and external auditors, regulators and end users of the system).

Blockchain State

The persistent state maintained by each full node in the blockchain network, which transactions are applied to. The consensus algorithm ensures that the blockchain state (not only the transaction log) is identical for all full nodes.

In Exonum, the blockchain state is implemented as a key-value storage. It is persisted using LevelDB. The parts of the storage correspond to tables used by the core and services.

Byzantine Node

Node in a distributed network that acts outside of the behavior prescribed by the consensus algorithm in the network. Byzantine behavior may be caused by a malicious intent, malfunctioning software/hardware, or network connectivity problems.

Consensus algorithms that are able to withstand Byzantine behavior are called Byzantine fault-tolerant (BFT). Exonum uses BFT consensus inspired by PBFT. Exonum is able to tolerate up to 1/3 of validators acting Byzantine, which is the best possible number under the security model that Exonum uses.


Set of configurable parameters that determine the behavior of a full node. Configuration consists of 2 parts: global configuration and local configuration. Certain configuration parameters are defined by the core, e.g., the maximum number of transactions in a block. Services can define and manage additional configuration parameters, too.


See Configuration for more details.


Aka consensus algorithm

Mechanism of reaching agreement among nodes in a network. In the blockchain context, consensus is required to withstand faults: nodes being non-responsive and/or outright trying to compromise the operation of the blockchain.

There are 2 main types of consensus:

  • Authenticated consensus, in which the participating nodes are known in advance. This is the type of consensus implemented in Exonum
  • Anonymous consensus, in which the consensus participants are not known in advance. This type of consensus is commonly used in cryptocurrencies (e.g., Bitcoin)

Consensus Message

Message generated by a full node as prescribed by the consensus algorithm. Validators exchange consensus messages to commit transactions to the blockchain by creating new blocks.

Consensus messages include:

  • Propose, Prevote and Precommit messages that correspond to 3 phases of the consensus algorithm used in Exonum
  • Request messages used by full nodes to request missing data from peers
  • Block message used to transmit an entire block of transactions to a lagging full node
  • Auxiliary messages, such as Status and Connect


See Consensus and Requests for more details.


In Exonum: the functionality present in any Exonum blockchain regardless of the deployed services. Encapsulated in the exonum repository.

For example, the core includes a collection of system tables (such as a set of all transactions ever committed to the blockchain).


Absence of a single point of failure in the system. For example, absence of a single administrator having privileges to perform arbitrary actions.

Digital Signature

Aka signature

Public-key digital signature in the Ed25519 elliptic curve cryptosystem. A signature over a message proves that the signer knows a specific private key corresponding to a publicly known public key. A signature can be verified against this public key and the signed message, thus providing message authenticity (i.e., the message comes from a specific source) and integrity (the message is not modified after being signed). Ed25519 signatures are universally verifiable, meaning that a verifier doesn’t need to know any additional information to verify a signature.

Implementation details

Ed25519 digital signatures occupy 64 bytes in the binary form. Exonum uses the sodiumoxide Rust crate (a libsodium binding for Rust) to create and verify digital signatures on full nodes, and TweetNaCl.js to do the same operations on light clients.

Distributed Ledger

A distributed system that maintains a full transaction log for all operations in the system, so that any piece of data in the system has a verifiable audit trail. All transactions are authenticated, usually via public key cryptography used together with some form of timestamping to provide non-repudiation.


In a generic distributed ledger, the audit trail may be dispersed across the system participants. Thus, it may be difficult to argue about consistency of the whole system.

Blockchains are a particular kind of distributed ledgers with focus on auditability and accountability of the system maintainers.

Full Node

Aka peer

Node in the blockchain network that replicates all transactions in the blockchain and thus has a local copy of the entire blockchain state. There are 2 categories of full nodes in Exonum: validators and auditors.

Genesis Block

The very first block in the blockchain. The genesis block does not link to the hash of the previous block in the blockchain; instead, this link is filled with a placeholder (32 bytes of zeros). The genesis block contains an initial global configuration and no other transactions.

Global Configuration

Part of configuration common for all full nodes. The global configuration is a part of the blockchain state. The core defines several global configuration parameters, which are mostly related to consensus and networking (e.g., a set of validators’ public keys).


Aka cryptographic hash

SHA-256 cryptographic hash digest of certain data. Exonum uses hashes as unique identifiers for transactions. Hashes are also used to create Merkle trees and their variants.

Implementation details

SHA-256 hashes occupy 32 bytes in the binary form. Exonum uses sodiumoxide to calculate hashes on full nodes and sha.js to do the same on light clients.

JSON Serialization

Serialization of data stored in the blockchain and messages into JSON. JSON serialization is used in Exonum for service endpoints. It is implemented both in the core and in the light client library.

Light Client

Aka lightweight client, thin client

Node in the blockchain network that does not replicate all transactions in the blockchain, but rather only a small subset that the client is interested in and/or has access to. Light clients can communicate with full nodes to retrieve information from the blockchain and initiate transactions. The proofs mechanism allows to minimize the trust during this communication and protect the client against a range of attacks.

Local Configuration

Part of configuration local to every full node. The local configuration is not a part of the blockchain state; instead, it’s maintained as a local TOML file, which is read during the node startup. The core defines several local configuration parameters, such as the private key used to sign consensus and network messages created by the node.


An entity participating in creating blocks and setting the rules on a blockchain.

In permissioned blockchains, maintainers have known real-world identities, which is reflected in the blockchain protocol. The maintainers set up and administer validator nodes in the network, and agree on the changes in the transaction processing rules.


Consider an Exonum blockchain that implements public registry in a particular country. In this case, the maintainers of the blockchain are government agency or agencies, which are tasked with maintaining public registries by law.

In contrast, in permissionless blockchains (e.g., Bitcoin), maintainers are not reflected within the blockchain protocol. Validators in such networks are usually pseudonymous.

Merkle Proof

Cryptographic proof that certain data is a part of the cryptographic commitment based on Merkle trees or their variants. A Merkle proof allows to compactly prove that a certain data is stored at the specified key in the blockchain state. At the same time the proof does not reveal other information about the state and does not require to replicate all transactions in the blockchain network.

Merkle proofs are used in Exonum in the responses to read requests by light clients. Using proofs, a client can verify the authenticity of the response without needing to communicate with multiple full nodes or replicating all transactions in the blockchain.

Merkle Tree

Aka hash tree

Data structure based on a binary tree that allows to calculate an aggregate hash from a list of elements in such a way that any particular element of the list is tied to the overall hash via a short link. (This link is called a Merkle path or Merkle proof.)

Exonum uses Merkle trees and a similar data structure for maps (Merkle Patricia tree) to collect the entire blockchain state into a single state hash recorded in blocks, and to provide proofs to light clients.


In cryptographic terms, a Merkle tree implements a commitment scheme to the list of elements in such a way that the size of any opening of the commitment is logarithmic with respect to the number of elements in the list.


A digitally signed piece of data transmitted through an Exonum network. There are 2 major kinds of messages:

Permissioned Blockchain

Blockchain, the maintainers of which are a limited set of entities with established real-world identities. Accordingly, validator nodes in a permissioned blockchain are few in numbers and are authenticated with the help of public-key cryptography.

Permissioned blockchains usually use variations of authenticated consensus.

Private API

Service endpoint that can be used to administer a local instance of the service. As an example, private API can be used to change the local configuration of the service.

Private Key

Private key as per the Ed25519 specification. Each private key corresponds to a specific public key. The knowledge of a private key is necessary to create digital signatures over messages, which could be later verified against the message and the corresponding public key.

Implementation details

As per libsodium, private keys occupy 64 bytes in the binary form: 32 bytes for the cryptographic seed used to generate the key, and 32 bytes for the pre-calculated corresponding public key. The latter 32 bytes are redundant, but help speed up computations.

Public Key

Public key as per the Ed25519 specification. Public keys are used to verify digital signatures over messages. A public key can be linked with a real-world identity. For example, public keys used in consensus are tied to specific validators, as only a specific validator is assumed to know the corresponding private key.

Implementation details

As per libsodium, public keys occupy 32 bytes in the binary form.

Read Request

Service endpoint that can be used to retrieve data from the blockchain state. The data is usually returned with a proof that the data is indeed a part of the blockchain state and has been authorized by a supermajority of validators.


Process of converting Exonum data structures to a language-independent representation. Exonum defines (de)serialization rules for stored datatypes and messages. Each of these can be converted from/to 2 representations: binary and JSON.


The main extension point of the Exonum framework, similar in its design to a web service. Services define all transaction processing logic in any Exonum blockchain.

Externally, a service is essentially a collection of endpoints that allow to manipulate data in the blockchain state and retrieve it, possibly with proofs. Internally, a service may define a bunch of stuff, including table schema, configurable parameters, etc.


See Services for more details.

Service Endpoint

A point of communication with a service. There are three kinds of endpoints:

External entities such as light clients can access endpoints via REST API. The configuration for REST API is specified in the service.

Stored Datatype

Datatype capable to be stored as a value in the Exonum key-value storage. Stored datatypes use binary serialization logic to convert data to a platform-independent representation.


See Storage for more details.


A structured collection of data (e.g., a map, set or a list) that provides a high-level abstraction on top of the blockchain state. Tables are used by services to simplify data management. Additionally, some types of tables allow to efficiently compute Merkle proofs for table items.


An atomic patch to the blockchain state satisfying ACID criteria. Transactions are authenticated with the help of public-key digital signatures; i.e., the authorship of each transaction is known and cannot be easily repudiated. Transactions may be generated by various entities in the blockchain network, such as light clients.

Transactions are ordered and grouped into blocks in the course of the consensus algorithm. Thus, transactions are applied in the same order on all full nodes in the blockchain network.

In Exonum, transactions are a subtype of service endpoints. All transactions are templated and defined within services, acting similarly to stored procedures in database management systems. Transaction endpoints of a service usually specify certain verification rules, such as the validity of a digital signature in the transaction. If the rules don’t hold for a particular transaction, it does not change the blockchain state, but may still be recorded in the transaction log.


See Transactions for more details.


A full node in the blockchain network with the right to participate in the consensus algorithm to create blocks. In Exonum, validators are identified with the help of the global configuration, which contains public keys of all validators in the network. The set of validators can be changed by changing the global configuration. Usually, the set of validators is reasonably small, consisting of 4–15 nodes.