Ethereum Key Terms
An acronym for "application binary interface" that is used for client-side JSON/RPC communication with a smart contract on the Ethereum blockchain. Allows for the proper encoding and decoding of EVM compatible instructions.
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.
A submodule of the Quorum Tessera module that works in conjunction with the transaction manager to handle certain crypto-operations such as symmetric key generation and data encryption/decryption. See the Mechanics of a Private Transaction in Quorum documentation for further details.
Also referred to as a "User" account in Kaleido. Used for transaction signing and state storage within instantiated smart contracts. By default, nodes on Kaleido will sign transactions with the private key of their default user account unless an external signing key is used on the client side prior to submitting the transaction object 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.
A hardened Go implementation of the Ethereum node client. Offers support for public transactions and clique PoA consensus.
Istanbul BFT (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 available with Quorum and Pantheon.
Refers to the leading node in Raft consensus that mints and delivers blocks to the entirety of the network (i.e. the followers).
An enterprise-grade Java based Ethereum client that can be used develop enterprise applications requiring secure, high-performance transaction processing in a private network. Pantheon supports enterprise features including privacy and permissioning.
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.
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.
A fork of the Geth client that includes a Tessera module allowing for private transaction processing and crypto-operations. Quorum supports Raft or Istanbul BFT consensus mechanisms and stores successfully processed private transactions in a separate Patricia Merkle Trie. See the Mechanics of a Private Transaction in Quorum documentation or the Quorum Wiki for further details.
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.
Refers to a node in an environment with Istanbul BFT or clique 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.
A programmable piece of software exposing methods for reads and writes that also maintains its own world state around the state and ownership of assets. Smart contracts must be written in a language that compiles down to EVM interpretable byte code. Typically written in Solidity. Smart contracts can leverage an event interface to emit designated transaction information when one or more methods are invoked.
A technique for modeling digital and real world assets on the blockchain. Tokens can be fungible or non-fungible and can be dynamically exchanged through atomic swaps and escrow smart contracts.
A submodule of the Quorum Tessera module responsible for private transaction processing. Stores hashes, encrypted payloads and encrypted symmetric keys related to specific private transactions. See the Mechanics of a Private Transaction in Quorum documentation or the Quorum Wiki for further details.
Designated nodes within an Istanbul BFT or clique PoA 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.
A management utility for key storage. Wallets can contain multiple accounts for usage on different networks/environments and separation of asset ownership. For example, you may want one account for ownership of fungible tokens and another account for ownership of non-fungible real world assets. Kaleido provides a convenient service called EthWallet for easy storage of any node or external account under your control.