Ethereum Core Concepts

Ethereum Virtual Machine

The Ethereum Virtual Machine or EVM is the runtime environment for smart contracts in Ethereum. It is sandboxed and completely isolated, meaning that code running inside the EVM has no access to the network, filesystem or other processes. Smart contracts even have limited access to other smart contracts.

Node

The node encapsulates the EVM and is ultimately responsible for processing transactions, maintaining state, and participating in p2p consensus protocols. The Kaleido platform currently offers Geth, Quorum and Hyperledger Besu as available node client implementations. A fork of the main Geth interface, Quorum offers support for basic public transactions as well as private transactions through its ancillary Tessera module. The Geth client is the public Ethereum interface programmed in Golang, which unlike Quorum, offers support for solely public transactions. Besu is a modular Java-based client built from the ground up for enterprise usage.

Smart Contract

Ethereum smart contracts are most commonly written in Solidity, a high-level contract oriented language designed to target the Ethereum Virtual Machine (alternative languages such as Vyper or Flint can be utilized as well). Smart contracts contain the list of instructions to be executed when one of its functions is invoked, as well as optional restrictions on which parties can call a function. Solidity compiles into byte code (machine code), as do all EVM-compatible languages, and uses an application binary interface (ABI) to encode/decode data into/out of the machine code. Every deployed contract exists as an independent instance, with a unique address and state information constrained to itself.

Consensus

In short, because distributed systems act independently when processing information (i.e. executing transactions) and updating state, there must be non-disputable agreement in the resulting states among the nodes. The process of achieving the agreement among the distributed nodes’ states is called consensus.

Two flavors of consensus are available alongside the Quorum client - Raft and IBFT. Raft consensus is a crash fault tolerant mechanism that provides high speed block committals, but is inherently reliant on the integrity of the “leader” node. Blocks minted in Raft consensus are not protected by either a unique hash or by validating signatures, and, as a result, it is technically feasible to modify historical data. Therefore, Raft should only be selected in scenarios of unequivocal trust. The second flavor, Istanbul BFT, is a Byzantine Fault Tolerant protocol that follows the PBFT implementation allowing up to f number of dishonest (faulty) nodes to be tolerated in a network of 3_f_ + 1 nodes. Additionally, Istanbul BFT offers further protections through the collection of signatures from the block proposer and voting validator nodes. Please refer to the Consensus Considerations blog post for a deeper dive on the advantages and drawbacks of each.

The Geth client currently offers clique Proof of Authority or PoA as the available consensus algorithm. PoA involves a set of nodes designated as trusted “signers” taking turns signing and disseminating blocks to the network. The algorithm prevents a signer from issuing multiple blocks in a row, and is dynamic such that the list of signers can be adjusted to protect against attack vectors.

Ledger

The ledger in an Ethereum blockchain network consists of two key pieces - a hash-linked chain of blocks and a state trie. The hash chain is a cryptographically-linked series of immutable blocks that contain the record of all executed transactions on the network. Each block contains the hash of the previous block within its header, thus the term hash chain. The state trie, also referred to as world state, is the current state or value of any variables defined within the deployed smart contracts. In the case of Quorum, if a private transaction is initiated then the specified recipients will use the Quorum client’s private state trie to store state updates. Regardless of transaction class (public v private), all nodes maintain an identical copy of the hash chain.

Transactions are the signed objects that deploy smart contract byte code or call available functions to update a contract’s state. All Ethereum transactions require a “gas” parameter representing the maximum number of computational steps the transaction execution is allowed to take. Public Ethereum requires a “gas price” for all transactions to prevent against malicious behavior, however in the scope of permissioned networks, the price can typically be set to zero. Regardless of gas price, all transactions must enter the network as a properly formed Ethereum transaction object with specified values (in hexadecimal or plaintext) for nonce, gasPrice and gasLimit, and the arguments for to, data and value expressed strictly in hexadecimal. They must also be signed with the secp256k1 private key bound to the sending Ethereum account.

A byproduct of the Quorum client’s flexibility, both public and private transactions are supported. Public transactions follow the same flow as core Geth, where all nodes use the EVM to execute the Ethereum byte code and update state in their public Patricia Merkle Trie. Private transactions make use of the Tessera module and are configurable by specifying the private address (i.e. transaction manager public key) of the targeted node(s) in the privateFor parameter of the transaction payload. State information for private transactions is subsequently stored in the Quorum client’s private Patricia Merkle Trie. If a node is not specified as a privateFor recipient, it will have no visibility into the transaction inputs and rendered state information.

API

The majority of the Kaleido samples leverage the Web3.js client library, a popular Ethereum compatible javascript API that implements the generic JSON/RPC specification. The core web3 package houses several sub modules that allow programmatic interaction with nodes, accounts, addresses, etc. Refer to the formal web.js API documentation on the available web3.eth classes and methods. Alternative libraries (e.g. Nethereum, Web3j, Web3.py, etc.) can be utilized as well; the choice is left to the developer. Kaleido provides sample connection calls, viewable in the Developers section, for a number of the proven libraries in use today. Kaleido offers the REST API Gateway and EthConnect Services as a simplified transaction layer that abstracts the core JSON/RPC API and allows for applications to be developed using modern REST APIs without an Ethereum client library.