Unit 4: Ethereum blockchain and Distributed applications - Subjective Questions

Ethereum is an open-source, decentralized blockchain platform that enables developers to build and deploy smart contracts and decentralized applications (DApps). It was proposed by Vitalik Buterin in 2013 and went live in 2015.

Key features:

• A Turing-complete programming environment (via the Ethereum Virtual Machine).
• A native cryptocurrency called Ether (ETH) used to pay for computation (gas).
• Support for stateful smart contracts.

Difference from Bitcoin:

In short, Bitcoin is primarily a peer-to-peer electronic cash system, whereas Ethereum is a world computer that executes arbitrary code in a trustless manner.

The Ethereum network is a global, peer-to-peer network of nodes that collectively maintain and update the Ethereum blockchain.

Main components:

• Nodes: Computers running Ethereum client software (e.g., Geth, Nethermind). They validate transactions and blocks.
  • Full nodes store the entire blockchain state.
  • Light nodes store only block headers.
  • Archive nodes store all historical states.
• Miners / Validators: Produce new blocks. (Post-Merge, Ethereum uses Proof of Stake validators instead of PoW miners.)
• EVM: The runtime environment on every node that executes smart-contract bytecode.
• Consensus layer: Ensures all nodes agree on the canonical chain.

Types of networks:

• Mainnet: The live production network with real ETH.
• Testnets: Sepolia, Holesky — used for testing with valueless ETH.
• Private networks: Permissioned networks for enterprises.

Nodes communicate using the devp2p protocol and propagate transactions and blocks across the network.

The Ethereum ecosystem comprises the tools, protocols, and participants that enable the development and use of decentralized applications.

Major building blocks:

• Smart Contracts: Self-executing programs written in Solidity or Vyper.
• EVM (Ethereum Virtual Machine): Executes contract bytecode deterministically.
• Ether (ETH): Native cryptocurrency used for transaction fees and value transfer.
• Gas: Unit measuring computational effort required for operations.
• Development tools: Truffle, Hardhat, Remix IDE, Foundry.
• Wallets: MetaMask, hardware wallets for key management.
• Clients: Geth, Besu, Nethermind.
• Standards (ERC): ERC-20 (fungible tokens), ERC-721 (NFTs), ERC-1155.
• DApps & DeFi: Decentralized finance protocols, DAOs, marketplaces.
• Oracles: Chainlink and others that bring off-chain data on-chain.

Together these components create a rich environment for building trustless, programmable applications.

In Ethereum, keys form the basis of ownership and authentication, following public-key (asymmetric) cryptography.

Private key:

• A randomly generated 256-bit number.
• Must be kept secret; it is used to sign transactions.

Public key:

• Derived from the private key using the ECDSA algorithm on the secp256k1 elliptic curve.
• 512 bits (uncompressed, 64 bytes).

Address derivation steps:

1. Generate a random private key .
2. Compute the public key (elliptic curve point multiplication).
3. Apply the Keccak-256 hash to the public key.
4. Take the last 20 bytes (160 bits) of the hash → this is the Ethereum address.

Addresses are prefixed with 0x and are 40 hexadecimal characters long. The relationship is one-way: you can derive the address from the key, but not vice versa.

An Ethereum transaction is a cryptographically signed instruction from an externally owned account (EOA) that triggers a state change on the blockchain, such as transferring ETH or invoking a smart contract.

Main fields of a transaction:

• Nonce: A sequential counter of transactions sent from the sender's account (prevents replay/double spending).
• Gas Price / Max Fee: The amount of ETH the sender is willing to pay per unit of gas.
• Gas Limit: The maximum amount of gas the transaction may consume.
• To: The recipient address (empty for contract creation).
• Value: Amount of ETH (in wei) to transfer.
• Data (Input): Optional payload — contract bytecode or function call data.
• v, r, s: Components of the ECDSA digital signature that prove authenticity.

Types:

• Value transfer (ETH between accounts).
• Contract creation (deploying a contract).
• Contract execution (invoking a function).

A valid transaction must be signed by the sender's private key and must pay sufficient gas fees.

Both transactions and messages trigger execution in Ethereum, but they differ in origin and persistence.

Message: When a contract calls another contract (or sends ETH), it produces an internal message (sometimes called an internal transaction). It contains sender, recipient, data, value, and gas.

Key point: Every message chain is ultimately triggered by an external transaction. Messages are the mechanism for contract-to-contract communication, while transactions are the external entry point.

Ether (ETH) is the native cryptocurrency of the Ethereum blockchain. It serves two main purposes:

• As a medium of value transfer between accounts.
• As fuel (gas) to pay for computation and storage on the network.

Denominations: The smallest unit is the wei. Common denominations include:

Thus:

gwei is especially important because gas prices are usually quoted in gwei. Using wei as the base integer unit avoids floating-point errors in value calculations.

The Ethereum Virtual Machine (EVM) is the runtime environment for smart contracts in Ethereum. It is a quasi-Turing-complete, stack-based virtual machine that executes contract bytecode.

Characteristics:

• Deterministic: The same input always produces the same output on every node.
• Sandboxed/Isolated: Code runs in a completely isolated environment with no access to the network, filesystem, or other processes.
• Stack-based architecture: Uses a LIFO stack with a maximum depth of 1024 and 256-bit words.
• Quasi-Turing-complete: Can execute arbitrary logic but bounded by the gas limit to prevent infinite loops.

Memory areas:

• Stack: Temporary values for computation.
• Memory: Volatile, reset after execution.
• Storage: Persistent key-value store written to the blockchain.

Execution: High-level code (Solidity) is compiled into EVM bytecode composed of opcodes (e.g., ADD, MSTORE, SSTORE, CALL). Each opcode has an associated gas cost. If gas runs out, execution halts and state changes are reverted (except the fee).

The EVM ensures that smart contracts behave identically across all nodes, forming the computational backbone of Ethereum.

Gas is the unit that measures the computational effort required to execute operations on Ethereum. Every operation (opcode) has a fixed gas cost, which prevents abuse and compensates validators.

Key terms:

• Gas Limit: Maximum gas a transaction may use.
• Gas Price: Price per unit of gas, usually in gwei.
• Gas Used: Actual gas consumed.

Fee calculation:

Example:
Suppose a simple ETH transfer uses gas and the gas price is gwei.

Post EIP-1559: The fee is split into a base fee (burned) and a priority fee / tip (to the validator):

If a transaction runs out of gas, it reverts but the consumed gas is not refunded.

Ethereum has two types of accounts, both identified by a 20-byte address.

EOA:

• Owned by a user; controlled by a private key.
• Can send ETH and trigger contract execution.

Contract Account:

• Created when a contract is deployed.
• Has associated code and persistent storage.
• Only executes when it receives a message/transaction.

Key point: A transaction must always originate from an EOA; contract accounts can only respond to being called. Both account types maintain a balance and nonce.

A Distributed Application (DApp) is an application whose backend logic runs on a decentralized peer-to-peer network (such as Ethereum) rather than a centralized server, using smart contracts for business logic.

Characteristics of DApps:

• Decentralized: No single point of control or failure.
• Open source and transparent.
• Trustless: Logic is enforced by code on-chain.
• Uses a cryptographic token or native currency.

Steps to implement a DApp:

1. Design the architecture: Decide on-chain (smart contract) vs off-chain (UI, storage) components.
2. Write smart contracts: Code business logic in Solidity.
3. Compile: Convert Solidity to EVM bytecode and generate the ABI.
4. Test: Use frameworks like Hardhat/Truffle on a local or test network.
5. Deploy: Publish the contract to the Ethereum network via a transaction.
6. Build the frontend: A web UI using web3.js or ethers.js.
7. Connect wallet: Integrate MetaMask for signing transactions.
8. Interact: Users call contract functions through the UI; results are recorded on-chain.

Architecture layers:

• Frontend (client): HTML/JS UI.
• Smart contract (backend logic).
• Blockchain (storage & execution).
• Optional: Decentralized storage (IPFS) and oracles.

An Event Registration DApp allows participants to register for an event in a transparent and tamper-proof manner using a smart contract.

Working / Design:

• A smart contract stores the list of registered participants, event capacity, and registration fee.
• Users send a transaction (optionally with ETH as a fee) to register.
• The contract validates conditions (capacity not full, fee paid, no duplicate).

Core contract logic (conceptual):
solidity
contract EventRegistration {
address public organizer;
uint public maxSeats;
uint public fee;
mapping(address => bool) public registered;
address[] public participants;

function register() public payable {
    require(msg.value >= fee, "Insufficient fee");
    require(!registered[msg.sender], "Already registered");
    require(participants.length < maxSeats, "Event full");
    registered[msg.sender] = true;
    participants.push(msg.sender);
}

}

Benefits:

• Transparency: Anyone can verify the participant list.
• Immutability: Registrations cannot be altered.
• Automation: Fee collection and seat limits are enforced by code.
• No central authority can tamper with records.

Events can be emitted (emit Registered(msg.sender)) so that the frontend can listen and update in real time.

Document Verification on Ethereum uses the blockchain's immutability to prove the authenticity and integrity of a document without storing the document itself on-chain.

Working:

1. The document is passed through a cryptographic hash function (e.g., Keccak-256 / SHA-256) to generate a unique fixed-length hash (fingerprint).
2. This hash is stored on the Ethereum blockchain via a smart contract, along with metadata (issuer, timestamp).
3. To verify, a user re-hashes the document and compares the hash with the one stored on-chain.
4. If the hashes match, the document is authentic and unaltered; any change produces a completely different hash.

Why only the hash is stored:

• Storing large files on-chain is extremely expensive (gas).
• The actual document can be kept off-chain (e.g., IPFS); only its hash goes on-chain.

Benefits:

• Integrity: Tampering is instantly detectable.
• Immutability: The stored hash cannot be modified.
• Timestamping: Proof of existence at a point in time.
• Privacy: Document content never exposed, only its hash.

Use cases: Certificates, degrees, land records, legal agreements, and supply-chain documents.

A Call Option is a financial derivative that gives the holder the right, but not the obligation, to buy an underlying asset at a predetermined strike price on or before a specified expiry date.

Key terms:

• Strike price: The agreed buying price.
• Premium: The fee paid by the buyer to the seller (writer) for the option.
• Expiry: The deadline to exercise.

Implementation as a smart contract:

• The writer deploys a contract locking the underlying asset (or ETH) and sets strike price, premium, and expiry.
• The buyer pays the premium to acquire the option.
• Before expiry, if the market price exceeds the strike price, the buyer can exercise by paying the strike price; the contract transfers the asset.
• After expiry, the writer can reclaim the locked asset if the option is unexercised.

Payoff for buyer at expiry:

where = spot price and = strike price.

Benefits of a smart-contract option:

• Automated settlement with no intermediary/broker.
• Trustless enforcement of terms.
• Transparency and reduced counterparty risk.

Price data of the underlying asset is typically fed via an oracle (e.g., Chainlink).

An Interest Rate Swap (IRS) is a financial derivative contract in which two parties exchange interest payments on a notional principal amount — typically one party pays a fixed rate while the other pays a floating rate (e.g., tied to a reference rate).

Mechanics:

• No exchange of the notional principal itself — only the interest flows are swapped.
• Party A pays fixed interest; Party B pays floating interest.
• Net difference is settled periodically.

Net payment formula per period:

where is the fraction of the year for the period.

Modeling on Ethereum:

• A smart contract stores the notional, fixed rate, floating rate reference, and payment schedule.
• An oracle supplies the current floating/reference rate at each settlement date.
• At each period, the contract calculates the net amount and automatically transfers ETH/stablecoins from one party to the other.
• Collateral may be locked to reduce counterparty default risk.

Benefits:

• Automated, trustless settlement.
• Reduced counterparty risk via on-chain collateral.
• Transparency and auditability of all cash flows.

This demonstrates how complex OTC financial instruments can be made programmable and self-executing.

Industrial IoT (IIoT) refers to the network of connected sensors, machines, and devices used in industrial settings (manufacturing, energy, logistics). Integrating Ethereum blockchain with IIoT addresses key challenges of trust, security, and automation.

Role of Ethereum in IIoT:

• Data integrity: Sensor data hashes are stored immutably on-chain, preventing tampering.
• Device identity & authentication: Each device gets a unique address/keys for secure identification.
• Automation via smart contracts: Contracts automatically trigger actions (payments, reorders, maintenance) based on sensor data.
• Decentralized trust: No single central server controls the data; multiple parties can trust shared records.
• Auditability: Full, transparent history of device events and transactions.

Example use cases:

• Supply chain tracking: Record temperature/location of goods; smart contract releases payment on delivery conditions.
• Predictive maintenance: Machine logs usage on-chain; a contract schedules/pays for servicing.
• Automated machine-to-machine (M2M) payments: Devices pay each other in ETH for services/resources.

Challenges:

• Scalability and throughput of the blockchain.
• Gas costs for frequent data writes (often mitigated by storing only hashes).
• Oracles needed to connect physical devices to on-chain logic.

Thus Ethereum provides a secure, automated, and trustless backbone for industrial IoT ecosystems.

Ethereum uses an account-based model where the global state is a mapping of addresses to account states.

An account state consists of four fields:

• Nonce: A counter representing the number of transactions sent (for EOAs) or contracts created (for contract accounts).
• Balance: The amount of wei owned by the account.
• StorageRoot: Hash of the root node of the account's storage trie (persistent data).
• CodeHash: Hash of the account's EVM code (empty for EOAs).

Role of the nonce:

• Ensures transaction ordering — transactions are processed in increasing nonce order.
• Prevents replay attacks and double-spending, since each nonce can be used only once.
• For contract accounts, the nonce counts the number of contracts created by that account.

Example: If an account's nonce is 5, the next valid transaction must have nonce 5; after it executes, the account nonce becomes 6. A transaction with a repeated or out-of-order nonce is rejected.

web3.js and ethers.js are JavaScript libraries that allow a frontend (DApp UI) to communicate with the Ethereum blockchain.

Why they are needed:

• Browsers cannot directly talk to Ethereum nodes; these libraries provide the bridge.
• They enable sending transactions, reading contract state, listening to events, and managing accounts/wallets.
• They encode/decode function calls using the contract ABI.

Comparison:

Typical workflow with either library:

1. Connect to a provider (e.g., MetaMask injected provider).
2. Obtain a signer (user's account).
3. Create a contract instance using the ABI and address.
4. Call read functions (no gas) or send write transactions (requires signing + gas).
5. Listen to emitted events to update the UI.

Both achieve the same goal; the choice depends on project needs and developer preference.

An Ethereum block groups together validated transactions and links to the previous block, forming the chain.

A block consists of three main parts:

1. Block Header — contains metadata, including:

• Parent Hash: Hash of the previous block (links the chain).
• State Root: Root hash of the global state trie after this block.
• Transactions Root: Root hash of the Merkle trie of transactions.
• Receipts Root: Root hash of transaction receipts.
• Timestamp: Time the block was created.
• Number: Block height.
• Gas Limit / Gas Used: Max and actual gas for the block.
• Difficulty / (PoS: no difficulty): Consensus-related data.
• Nonce / mix-hash (PoW legacy).

2. Transaction List: All transactions included in the block.

3. Ommers / Uncles (legacy PoW): References to valid but non-canonical blocks (not used in PoS).

Key points:

• The use of Merkle Patricia Tries (state, transactions, receipts) allows efficient and secure verification.
• Each block header's parent hash creates the immutable chain — altering any block invalidates all subsequent blocks.

This structure ensures integrity, verifiability, and tamper resistance of the Ethereum blockchain.

Events in Ethereum are a logging mechanism that smart contracts use to communicate that something has happened, allowing external applications (DApp frontends) to react.

How events work:

• Declared in a contract using the event keyword and triggered using emit.
• When emitted, event data is stored in the transaction's logs section (part of the receipt), not in contract storage.
• Logs are stored in the blockchain but are cheaper than storage and are not accessible from within contracts.

Example:
solidity
event Transfer(address indexed from, address indexed to, uint value);

function send(address to, uint value) public {
// ... logic ...
emit Transfer(msg.sender, to, value);
}

Indexed parameters:

• Up to 3 parameters can be marked indexed, becoming searchable topics for efficient filtering.

Importance for DApps:

• Frontend updates: Apps using web3.js/ethers.js can listen to events and update the UI in real time.
• Cheaper than storage: Logging data costs less gas than writing to storage.
• Historical querying: Past events can be queried to reconstruct activity.
• Decoupling: Off-chain services monitor on-chain activity without polling full state.

Thus events are essential for responsive, efficient communication between smart contracts and user interfaces.