Key Terms

application credential – A basic access authentication credential holding a 1:1 relationship with a member identity. Used in conjunction with a node or service endpoint to securely connect to a resource over negotiable TLS. Application credentials exist within the context of an environment and are directly bound to a membership in the consortium. See the Connect to your node topic for an explanation on how to leverage the credentials.

block explorer – An environment-specific utility service that provides realtime and historical snapshots of the blockchain. Can be used for transaction inspection, chain analytics and source code verification. See the Block Explorer topic for a deeper dive into the explorer’s functionality.

consensus – The process of achieving agreement among the state of distributed nodes that independently process transactions. See the Consensus Considerations blog post for a deeper dive on consensus in general and the flavors offered by Kaleido.

charter – Term used for the initial orchestration and configuration of a consortium. Defines the macro characteristics of the consortium: Name and Business Description.

enclave – A submodule of the Quorum constellation that works in conjunction with the transaction manager to handle certain crypto-operations such as symmetric key generation and data encryption/decryption. See the Private Transactions documentation for further details.

environment – An isolated domain used to host nodes/services and execute blockchain transactions. Each environment is a unique namespace that exists as a child resource of a consortium. All members of a consortium are whitelisted to environments and can own or be distinctly bound to nodes, services and application credentials. Node protocols and consensus algorithms are applied as configuration parameters to an environment, allowing for bespoke orchestrations to be crafted by the creating member.

Ethereum account – Also referred to as a user account in Kaleido. Needed for external application connection and proper EVM execution. By default, nodes on Kaleido will sign transactions with the account’s private key unless an external signing key is specified on the web3 call to the network. User accounts on the Kaleido platform do not require the presence of ether, however organizations can choose to leverage an environment-specific Ether Pool and implement its usage as they see fit. For example, ether could be used to prioritize transaction mining or enforce smart contract costs.

Geth – A hardened Go implementation of the Ethereum node client. Offers support for public transactions and clique PoA consensus.

Istanbul Byzantine Fault Tolerant (IBFT) – A Byzantine Fault Tolerant consensus algorithm that can tolerate up to f number of dishonest/faulty nodes in a network of 3f + 1 nodes. See the Consensus Considerations blog post and the IBFT proposal for a deeper dive on IBFT and the implications of selecting this algorithm. IBFT is only available with the Quorum client.

leader – Refers to the leading node in Raft consensus that mints and delivers blocks to the entirety of the network (i.e. the followers).

node id – A ten character string that serves to uniquely identify a node within an environment. Comprises the latter part of the node’s URL endpoint.

private address – The public key of a Quorum node’s transaction manager. This “address” is used as the argument for the privateFor field in a transaction payload in order to target specific nodes for private transactions.

Proof of Authority (PoA) – A consensus algorithm where authorized signers take turns “minting” blocks. Signers, who must be present in block headers, can be added or removed and no signer can consecutively mint blocks. See the Consensus Considerations blog post for a deeper dive on PoA and the implications of selecting this algorithm. PoA is only available with the Geth client.

proposer – The node in an IBFT consensus orchestration responsible for proposing new blocks to the set of validators. Proposers, in contrast to the RAFT leader, will be different in every block and round change. See the Consensus Considerations blog post and the IBFT proposal for a deeper dive on IBFT and the proposer role.

Quorum – A fork of the Geth client that includes a “constellation” module allowing for private transaction processing and crypto-operations. Quorum supports Raft or IBFT consensus mechanisms and stores successfully processed private transactions in a separate Patricia Merkle Trie. See the Private Transactions documentation or the Quorum Wiki for further details.

Raft – A crash fault tolerant consensus mechanism offering high speed block delivery by a static leader node. See the Consensus Considerations blog post for a deeper dive on Raft and the implications of selecting this protocol.

signing node – Refers to a node in an environment with IBFT or PoA consensus that actively participates in the consensus process by voting on the validity of proposed blocks and appending a digital signature to the block header.

transaction manager – A submodule of the Quorum constellation responsible for private transaction processing. Stores hashes, encrypted payloads and encrypted symmetric keys related to specific private transactions. See the Private Transactions documentation or the Quorum Wiki for further details.

validator – Designated nodes within an IBFT consensus orchestration responsible for validating the integrity of a proposed block against their own view of the blockchain. Validators are synonymous with “signers”, as they append their digital signature to the block header.