Blockchain Platforms and Execution Models

Introduction

A smart contract is not merely a program stored on a server. It is a program executed by a distributed network whose participants must agree on the resulting state. The platform therefore determines what the contract can do, who may invoke it, how execution is ordered, how failures are handled, how much execution costs, and what level of finality users can expect.

Blockchain platforms differ substantially. Public platforms permit broad participation and usually emphasize censorship resistance and transparency. Private platforms restrict participation and often optimize for organizational control, confidentiality, and throughput. Consortium platforms distribute governance among a defined group of organizations. These differences are central to selecting an appropriate platform for a business or technical use case.

Ethereum is the most influential general-purpose public smart-contract platform. Understanding Ethereum requires understanding the Ethereum Virtual Machine (EVM), accounts, state, transactions, blocks, nodes, clients, consensus, finality, gas, and transaction fees. These concepts also provide a foundation for comparing Ethereum with other blockchain environments.

Learning Objectives

By the end of this chapter, you should be able to:

1. Distinguish public, private, and consortium blockchain platforms.
2. Explain Ethereum’s execution model and the role of the EVM.
3. Describe externally owned accounts, contract accounts, state, transactions, blocks, nodes, and clients.
4. Explain gas, transaction fees, block capacity, and fee estimation.
5. Distinguish transaction inclusion, confirmation, and finality.
6. Evaluate blockchain platforms using technical, economic, governance, legal, and operational criteria.
7. Recommend a platform architecture for a practical application.

1. Platform Types and Governance Models

A blockchain platform is a combination of a distributed ledger, a consensus mechanism, an execution environment, networking protocols, data storage, and governance arrangements. The word “permission” describes who may participate, but it does not by itself determine whether the ledger is decentralized or whether smart contracts are supported.

Public platforms

A public, or permissionless, blockchain allows anyone—subject to protocol rules—to read ledger data, submit transactions, and often operate a node. Examples include Ethereum and Bitcoin. Public networks commonly use economic incentives and cryptographic verification to coordinate participants who do not necessarily trust one another.

Advantages include:

• broad accessibility and composability;
• resistance to unilateral control;
• transparent verification of transactions and contract code;
• a large potential user and developer community; and
• strong availability through geographically distributed nodes.

Limitations include variable transaction fees, public visibility of activity, governance disputes, regulatory complexity, and lower throughput than many centralized systems. Confidential business information generally cannot be placed directly on a public ledger without encryption, privacy technology, or an off-chain design.

Private platforms

A private blockchain is controlled by one organization or a closely controlled administrative domain. Participation, validation, and access to data are restricted. Such systems may use conventional fault-tolerant consensus rather than mining or open economic staking.

Private platforms can provide predictable performance, stronger access control, and improved confidentiality. They are useful where one organization must coordinate several internal departments or subsidiaries while retaining administrative authority. Their disadvantages include reliance on a central operator, reduced neutrality, and the possibility that a conventional database would be simpler, cheaper, and more transparent.

Consortium platforms

A consortium, or federated, blockchain is governed by several known organizations. A bank consortium, logistics network, or group of healthcare institutions may jointly operate validator nodes. Membership is permissioned, but control is distributed among participating institutions.

Consortium platforms can provide shared governance, predictable transaction costs, and controlled disclosure. They also introduce membership disputes, coordination costs, and the risk that a small number of members can dominate decisions. The quality of decentralization depends on the number, independence, geography, and incentives of the participating organizations—not merely on the number of validator servers.

Comparative framework

The selection question is not “Which type is best?” It is “Which trust, access, privacy, performance, and governance assumptions does the application require?”

2. Ethereum as a General-Purpose Platform

Ethereum is a public blockchain designed to maintain a shared state and execute general-purpose programs called smart contracts. A contract can hold assets, enforce rules, emit events, and call other contracts. Because every validating node must be able to reproduce the result of execution, Ethereum contracts are normally deterministic: the same valid input and prior state should produce the same resulting state.

Ethereum’s execution environment is the Ethereum Virtual Machine. Since the transition to proof-of-stake consensus, Ethereum’s architecture is commonly described through two interacting layers:

• Execution layer: processes transactions, executes EVM code, maintains account state, and calculates gas.
• Consensus layer: coordinates validators, blocks, attestations, fork choice, and economic finality.

This separation does not mean that execution and consensus are unrelated. A block proposed and accepted by the consensus layer contains execution payloads whose transactions must be valid under the execution-layer rules.

3. The Ethereum Virtual Machine

The EVM is a deterministic, stack-based virtual machine. Smart-contract bytecode is executed using opcodes that manipulate a stack, memory, persistent storage, and the transaction environment.

Important EVM characteristics include:

• Stack-based execution: most instructions read values from and write values to a stack.
• Word size: EVM arithmetic operates primarily on 256-bit words.
• Memory: temporary and expandable during a call; it is not persistent between transactions.
• Storage: contract-specific persistent key-value data, whose use is relatively expensive.
• Calldata: read-only input supplied with a transaction or contract call.
• Logs: event data recorded in transaction receipts and indexed for applications, but not used as contract-readable storage.
• Determinism: execution must be reproducible by independent nodes.
• Gas metering: computational and storage operations consume protocol-defined gas.

Solidity is a popular high-level language for EVM contracts, but the EVM executes compiled bytecode, not Solidity source code. Other languages and compilation tools can target the EVM. Contract source-code verification is valuable because bytecode alone is difficult for users to inspect, although verification does not guarantee that a contract is correct or safe.

A contract cannot normally access arbitrary external information directly. For example, a contract cannot reliably query a web server during deterministic execution. An oracle or an authorized data submission process is required to bring external information on-chain. This creates an important trust boundary: the blockchain can verify the submitted transaction and contract logic, but it cannot automatically verify that an external data provider reported the truth.

4. Accounts and Ethereum State

Ethereum represents control and contract behavior through accounts. The global state maps addresses to account information. At a conceptual level, an account includes a balance, a transaction sequence number called a nonce, and—depending on the account type—code and storage.

Externally owned accounts

An externally owned account (EOA) is controlled by a private key. The corresponding public key is used to derive an address. The private key is not stored on the blockchain. A valid digital signature proves that the transaction was authorized by the holder of the key, but it does not reveal the private key.

EOAs can initiate transactions, hold ether, and interact with contracts. Key loss can mean permanent loss of control. Conversely, theft or unauthorized disclosure of a private key can allow an attacker to move assets or invoke contracts.

Contract accounts

A contract account is controlled by code deployed at an address. It does not independently originate transactions; it responds to transactions or calls. Its persistent storage records application state, such as token balances, ownership records, or voting proposals.

A contract may hold ether and may call other contracts. However, a contract’s behavior is limited by its deployed code and the permissions encoded in that code. A poorly designed administrator function, upgrade mechanism, or oracle dependency can create a powerful control point despite the decentralized infrastructure.

State transitions

Ethereum can be understood as a state-transition system. Let S_t represent the state before a transaction and T_t represent a valid transaction. Conceptually:

Here, F is the protocol-defined state-transition function. The equation is a conceptual model rather than a complete implementation formula. It assumes that the transaction is valid, execution is deterministic, and all required protocol rules are applied. A transaction may update balances, nonces, contract storage, logs, and other state-related values.

The state is not simply a list of transactions. Transactions are historical instructions; state is the current result of applying valid instructions in order. A node may reconstruct state from historical data, while optimized clients use additional databases and synchronization methods.

5. Transactions, Calls, and Blocks

A transaction is a signed instruction submitted for inclusion in the network. Depending on its type, it may transfer ether, deploy contract code, or invoke a contract function. Common transaction fields include the sender’s signature, nonce, destination, value, input data, gas limit, and fee-related parameters.

A transaction must be signed by the account authorized to send it. The nonce prevents accidental replay of the same transaction from an account and establishes an ordering sequence for that account. Transactions from different accounts can be ordered differently, subject to block and consensus rules.

A contract call made locally through an application interface may be an eth_call-style read operation. Such a call is simulated by a node and does not normally create a state change or require a paid on-chain transaction. A state-changing interaction requires a signed transaction and can incur a fee even if the contract execution ultimately reverts, because network resources were consumed.

A block is an ordered container of transactions and associated metadata. It links to earlier blocks and includes commitments that allow nodes to verify relevant data. The block producer or proposer selects transactions according to protocol and fee-market rules, while other nodes verify the block and its execution results.

Transaction ordering matters. If two transactions interact with the same contract state, changing their order can change the result. This creates risks such as front-running and sandwich attacks in public markets. Applications may require commit–reveal schemes, private transaction channels, batch auctions, or other mechanisms to reduce harmful ordering effects.

6. Nodes, Clients, and Network Operation

A node is a computer participating in the blockchain network. Nodes differ in their responsibilities and storage requirements. A full node independently verifies protocol rules and maintains enough data to serve the network and answer queries. An archive node retains extensive historical state information and requires substantially more storage. A light client obtains selected information from fuller nodes and verifies it using protocol proofs or consensus information.

A client is software that implements protocol rules. Ethereum uses separate execution clients and consensus clients. The execution client handles transaction execution, the EVM, the transaction pool, and the execution state. The consensus client handles proof-of-stake duties such as fork choice, validator communication, and attestations. An engine interface connects the two layers.

Client diversity is an operational and security concern. If nearly all validators use one implementation and that implementation contains a critical defect, the network may experience a correlated failure. Using multiple independently developed clients can reduce this risk, although diversity also increases testing and operational complexity.

Applications often connect through a remote procedure call (RPC) endpoint. An RPC provider offers access to nodes, but an application should not assume that one provider is always available or neutral. Production systems may use multiple providers, monitor chain identifiers and block consistency, rate-limit requests, and validate responses where security requires it.

7. Consensus, Confirmations, and Finality

Consensus determines which valid transactions belong to the canonical chain and in what order. Ethereum uses proof-of-stake. Validators deposit stake, participate in block proposal and attestation, and can be penalized for certain forms of misbehavior or failure. The consensus mechanism is distinct from EVM execution: consensus selects and secures the chain, while execution determines the result of transactions in each block.

Three related concepts should be distinguished:

1. Submission: a transaction has been broadcast to one or more nodes.
2. Inclusion: the transaction has been placed in a block accepted by the network.
3. Finality: the protocol has reached a strong consensus condition under which reverting the finalized history would require severe disruption and economic consequences.

A transaction can be included but not yet finalized. Applications with low-value or reversible actions may accept a recent inclusion. High-value settlements may wait for stronger confirmation or protocol finality. “Final” should therefore be defined operationally: an application should specify which network signal it trusts and what risk threshold it accepts.

In Ethereum’s proof-of-stake design, validators operate in time periods called slots and epochs. Blocks are proposed in slots, and finality is reached through the consensus protocol after appropriate validator attestations. Exact timing and liveness depend on network conditions and validator participation. Finality is not the same as legal settlement, business irreversibility, or protection from bugs in the contract itself.

8. Gas and Transaction Fees

Gas measures the computational and storage work required by EVM execution. Different operations have different gas costs. Gas is not ether and is not a direct measure of elapsed time; it is a protocol accounting unit for resource consumption.

A transaction specifies a gas limit, which is the maximum gas it is permitted to consume. If execution needs more gas than the limit, execution fails and state changes are reverted, although the consumed gas is still charged. If execution uses less than the limit, the unused portion is not charged as used gas.

Under Ethereum’s fee mechanism, a useful expression for the effective fee is:

For an EIP-1559-style transaction, the effective gas price is generally:

subject to the transaction’s maximum fee constraints. The base fee is protocol-determined and is burned; the priority fee (tip) is offered to the block proposer. A transaction also specifies a maximum fee per gas, which caps what the sender is willing to pay. If the maximum fee is below the required base fee, the transaction cannot be included under those terms.

The formula assumes that gas used and the effective gas price are expressed in compatible units. Gas is unitless for accounting purposes, while the gas price is commonly expressed in wei per gas. Since 1 ether = 10¹⁸ wei, the ether-denominated fee is:

Worked example

Suppose a transaction uses 50,000 gas. The base fee is 20 gwei and the priority fee is 2 gwei. The effective price is therefore 22 gwei per gas. The fee is:

50,000 × 22 = 1,100,000 gwei

Because 1,000,000 gwei = 0.001 ether, the fee is 0.0011 ether. This calculation assumes the transaction is included at that effective price and that no additional application-level fee is charged.

A higher gas limit does not automatically mean a higher final fee; the fee is based on gas actually used, while the limit caps possible consumption. However, a sender must maintain enough balance to cover the maximum permitted cost and value transfer. Contract developers should minimize unnecessary storage writes, avoid unbounded loops, and test gas behavior under realistic state sizes.

9. Execution Risks and Design Constraints

Smart-contract execution is powerful but constrained. Common risks include:

• Reentrancy: an external call causes control to return before internal accounting is complete.
• Access-control failure: a function can be invoked by an unintended address.
• Integer and precision errors: arithmetic assumptions do not match token or financial requirements.
• Oracle manipulation: external price or event data can be falsified or temporarily distorted.
• Denial of service: an operation becomes too expensive or fails because of unbounded data.
• Upgrade risk: an upgrade administrator or proxy can change behavior after deployment.
• Composability risk: a dependency fails, changes behavior, or is exploited.
• Transaction-order dependence: a public mempool exposes pending actions to strategic actors.

A formal audit can identify classes of defects, but no audit guarantees safety. Best practice combines threat modeling, tested access control, unit and integration testing, static analysis, fuzzing, independent review, monitoring, incident procedures, and carefully designed upgrade governance.

10. Selecting a Blockchain Platform

Platform selection should begin with requirements rather than brand preference. A structured assessment may consider the following dimensions.

Trust and governance

Who operates validators? Can a single organization censor or rewrite records? Who can change protocol parameters? What dispute-resolution process exists? Public Ethereum offers broad neutrality but slower social coordination for application-specific changes. A consortium can align governance with business relationships but requires durable member agreements.

Privacy and identity

Does the application require public auditability, confidential transactions, selective disclosure, or legally identifiable participants? Public ledgers expose metadata even when identities are represented by addresses. Permissioned systems can integrate identity controls, but access restrictions do not automatically guarantee privacy from administrators or consortium members.

Performance and cost

Define required transaction volume, latency, burst behavior, maximum transaction size, and fee predictability. A platform that performs well in a laboratory may perform differently under congestion. Consider total cost of ownership, including node operation, security monitoring, integration, key management, compliance, and disaster recovery.

Execution and ecosystem

Assess language support, developer tools, wallets, libraries, oracle services, testing environments, indexers, custody providers, and interoperability. EVM compatibility can reduce migration and hiring costs, but compatibility must be tested rather than assumed: opcode support, fee markets, precompiles, finality, and bridge assumptions may differ.

Security and resilience

Examine validator concentration, client diversity, history of incidents, upgrade processes, bug-bounty programs, and recovery mechanisms. Determine whether the platform supports hardware security modules, multi-signature controls, role separation, and auditable administration.

Legal and regulatory fit

Assess data-protection obligations, financial regulation, consumer protection, sanctions screening, record-retention requirements, and the legal status of tokens. Immutability can conflict with requirements to correct, delete, or restrict personal information. A sound design stores personal data off-chain and places only necessary commitments or references on-chain, subject to legal review.

A weighted decision matrix can make assumptions explicit. For each criterion, assign a weight w_i such that the weights sum to 1, and assign each candidate a score s_i on a defined scale. The weighted score is:

This is a decision aid, not an objective truth. Scores are only meaningful when criteria, scales, evidence, and risk tolerances are documented. A platform should not win solely because it has the highest numerical score if it fails a mandatory legal, privacy, or security requirement.

11. Applied Case: A Consortium Cold-Chain Ledger

Background

This illustrative case concerns four food distributors, two logistics companies, and a regulator seeking to improve traceability for temperature-sensitive products. Each organization already operates an internal database, but participants disagree about which records are authoritative after a shipment is transferred.

Problem

The participants require a shared history of custody transfers, inspection events, and temperature exceptions. They do not want product volumes, commercial prices, or customer information visible to the general public. They also require known organizational identities and predictable transaction costs.

Analysis

A public blockchain would offer independent auditability, but publishing detailed logistics records could expose commercially sensitive information. A single private blockchain operated by one distributor would be easier to control but would not resolve the trust problem among competing firms. A consortium platform is better aligned with the governance requirement because several organizations can operate validators and approve membership rules.

The system should not place raw temperature streams or personal information directly on-chain. Instead, authorized devices submit signed measurements to an off-chain storage system. A cryptographic commitment, shipment identifier, event type, timestamp, and responsible organization are recorded on the consortium ledger. The commitment allows later evidence to be checked for alteration without publishing every underlying document.

Approach and solution

A permissioned smart-contract system records:

1. creation of a shipment record;
2. transfer of custody between approved organizations;
3. inspection results and exception codes;
4. references to encrypted documents; and
5. dispute status and resolution authority.

Role-based permissions restrict which organization may record each event. Governance rules specify validator admission, software upgrades, emergency suspension, audit access, and dispute resolution. A regulator receives read access and can verify commitments, while sensitive documents remain accessible only to authorized parties.

Outcome

The design improves shared traceability without requiring public disclosure of commercially sensitive information. It does not eliminate trust: participants still trust device calibration, identity management, off-chain storage, and the consortium’s governance. The blockchain provides a tamper-evident shared sequence of agreed events, not proof that every physical event occurred exactly as reported.

Learning points

• Platform selection follows the trust and privacy model.
• A blockchain cannot make inaccurate input truthful.
• Hybrid on-chain/off-chain architecture is often more appropriate than storing all data on-chain.
• Governance, identity, and recovery must be designed alongside smart contracts.
• A conventional shared database should remain a serious alternative if the consortium can accept a trusted operator.

12. Contemporary Developments and Professional Practice

Ethereum development increasingly involves scaling systems such as layer-2 networks, which execute transactions outside the base layer and publish data or commitments for broader security. These systems can reduce user costs and increase throughput, but they introduce additional bridge, sequencer, withdrawal, and governance assumptions. A platform comparison must therefore examine the complete system, not only the settlement chain.

Account abstraction aims to make wallets programmable, enabling features such as sponsored fees, recovery policies, and batched actions. These features can improve usability but may add contract and relayer risks. Zero-knowledge techniques can support privacy or scalable verification, although they require specialized cryptographic engineering and careful implementation.

Artificial intelligence can assist with code explanation, test generation, anomaly detection, and monitoring. It should not be treated as an autonomous security authority. Generated code requires human review, reproducible tests, dependency analysis, and security validation. Because a deployed contract may be difficult or impossible to change, professional responsibility requires conservative release processes.

Best practice for platform projects includes documented requirements, explicit trust assumptions, threat modeling, minimal privileges, secure key management, independent testing, monitoring, incident response, upgrade transparency, and a clear explanation of what the blockchain does not guarantee.

Chapter Summary

Blockchain platforms differ according to participation, governance, privacy, performance, identity, and trust assumptions. Public platforms maximize open access and neutrality but can expose data and produce variable costs. Private platforms provide centralized control and predictable operation. Consortium platforms distribute authority among known organizations and are useful for inter-organizational coordination, but they require durable governance.

Ethereum maintains a shared state and executes deterministic smart-contract programs in the EVM. EOAs are controlled by private keys, while contract accounts are controlled by deployed code. Transactions request state changes; blocks order transactions; nodes verify and store network information; and clients implement execution and consensus responsibilities. Inclusion, confirmation, and finality are distinct operational concepts.

Gas measures EVM resource use. Transaction fees depend on gas used and the effective gas price, which incorporates the base fee and priority fee under the modern fee market. Platform selection should evaluate trust, privacy, identity, performance, cost, ecosystem, security, legal fit, governance, and total ownership cost. A blockchain is most valuable when its shared-state and coordination properties solve a real multi-party problem that cannot be addressed more simply by a conventional system.

Key Terms

Blockchain platform: A distributed system combining ledger storage, consensus, execution, networking, and governance.

Public blockchain: A broadly accessible blockchain in which participation is generally open.

Private blockchain: A blockchain controlled by one organization with restricted participation.

Consortium blockchain: A permissioned blockchain governed by multiple organizations.

Ethereum: A public blockchain platform supporting general-purpose smart contracts.

Ethereum Virtual Machine (EVM): The deterministic execution environment for Ethereum smart-contract bytecode.

Externally owned account (EOA): An account controlled by a private key.

Contract account: An account containing deployed code and persistent storage.

State: The current data produced by applying valid transactions to the ledger history.

Transaction: A signed instruction requesting a transfer, deployment, or contract interaction.

Block: An ordered package of transactions and related consensus metadata.

Node: A computer participating in blockchain networking, verification, storage, or service provision.

Client: Software implementing blockchain protocol functions.

Consensus: The process by which participants agree on the canonical chain and transaction order.

Finality: A strong protocol-level condition making reversal of history economically or technically difficult.

Gas: The unit used to account for EVM computation and storage resources.

Base fee: The protocol-determined component of an Ethereum transaction’s gas price that is burned.

Priority fee: An optional additional fee offered to the block proposer.

Oracle: A mechanism that supplies external information to a smart contract.

RPC endpoint: An interface through which applications communicate with a blockchain node or provider.

Review Questions

Short Answer Questions

1. What is the principal governance difference between a private and a consortium blockchain?
2. What is the role of the EVM?
3. Distinguish an externally owned account from a contract account.
4. Why is gas required for EVM execution?
5. What is the difference between transaction inclusion and finality?

Long Answer Questions

1. Compare public, private, and consortium platforms using participation, privacy, governance, performance, and security criteria.
2. Explain how Ethereum transactions cause changes to global state, including the roles of accounts, nonces, blocks, and execution.
3. Describe the responsibilities of Ethereum execution clients and consensus clients.
4. Explain Ethereum’s fee model and distinguish gas limit, gas used, base fee, priority fee, and effective gas price.
5. Develop a platform-selection framework for an organization choosing between a public EVM chain and a permissioned consortium platform.

Analytical / Application Questions

1. A healthcare consortium requires known identities, selective disclosure, shared audit records, and predictable costs. Recommend a platform type and explain what data should remain off-chain.
2. A transaction uses 80,000 gas at an effective price of 15 gwei. Calculate the fee in gwei and ether, assuming 1 ether = 10⁹ gwei. Explain what additional information would be needed to calculate the fiat cost.
3. A decentralized exchange exposes pending orders in a public transaction pool, allowing strategic reordering. Identify the platform risk and propose two design or operational measures to reduce it.

Multiple Choice Questions with Answers

Question 1

Which platform type is governed by several known organizations rather than one administrator?

A. Public blockchain

B. Private blockchain

C. Consortium blockchain

D. Standalone database

Correct Answer: C. Consortium blockchain

Question 2

What is the primary function of the EVM?

A. To store private keys for users

B. To execute Ethereum smart-contract bytecode deterministically

C. To determine legal ownership of physical goods

D. To replace all consensus validators

Correct Answer: B. To execute Ethereum smart-contract bytecode deterministically

Question 3

Which account type is directly controlled by a private key?

A. Externally owned account

B. Contract account

C. Archive account

D. Oracle account

Correct Answer: A. Externally owned account

Question 4

What does a transaction nonce primarily help prevent?

A. Block production

B. Replay and ordering problems for an account’s transactions

C. All smart-contract bugs

D. Changes to the base fee

Correct Answer: B. Replay and ordering problems for an account’s transactions

Question 5

Which statement best describes gas?

A. A cryptocurrency separate from ether

B. A measure of EVM resource consumption

C. A validator’s private key

D. A type of block signature

Correct Answer: B. A measure of EVM resource consumption

Question 6

A transaction uses 50,000 gas at 22 gwei per gas. What is the fee?

A. 1,100 gwei

B. 11,000 gwei

C. 1,100,000 gwei

D. 11,000,000 gwei

Correct Answer: C. 1,100,000 gwei

Question 7

Under the modern Ethereum fee model, which fee component is generally burned?

A. Base fee

B. Priority fee

C. RPC fee

D. Wallet service fee

Correct Answer: A. Base fee

Question 8

Which statement about a contract call simulated locally with an eth_call-style request is generally correct?

A. It always changes blockchain state

B. It normally does not create a paid on-chain transaction

C. It must be signed by every validator

D. It permanently deploys new bytecode

Correct Answer: B. It normally does not create a paid on-chain transaction

Question 9

Which statement correctly distinguishes finality from inclusion?

A. Inclusion means a transaction is in a block; finality is a stronger protocol settlement condition

B. Finality occurs before a transaction is broadcast

C. Inclusion and finality always mean exactly the same thing

D. Finality only describes the user’s wallet balance

Correct Answer: A. Inclusion means a transaction is in a block; finality is a stronger protocol settlement condition

Question 10

Which criterion is especially important when selecting a consortium platform?

A. Whether the platform has no governance rules

B. Whether validator membership and upgrade authority are clearly governed

C. Whether all data is publicly visible

D. Whether transactions require no identity controls

Correct Answer: B. Whether validator membership and upgrade authority are clearly governed