Unit 6: Ethereum, Web3 and Decentralized Applications - Subjective Questions

Ethereum is an open-source, decentralized blockchain platform designed to execute programmable applications called smart contracts.

Its major objectives and characteristics include:

• Programmability: Developers can encode application logic in smart contracts.
• Decentralization: The network is maintained by distributed nodes rather than a central authority.
• Ethereum Virtual Machine: The EVM provides a common execution environment for smart contracts.
• Native currency: Ether, represented by ETH, is used to transfer value and pay transaction fees.
• Immutability: Confirmed blockchain records are extremely difficult to alter.
• Transparency: Transactions and deployed contract code can generally be inspected publicly.
• Decentralized applications: Ethereum supports DApps in areas such as finance, gaming, identity, governance, and digital assets.
• Consensus: Modern Ethereum uses Proof of Stake, in which validators propose and attest to blocks.

Thus, Ethereum extends blockchain technology beyond digital currency by providing a general-purpose platform for decentralized computation.

The Ethereum network is a peer-to-peer distributed network in which nodes exchange transactions, blocks, and state information.

The network operates as follows:

1. A user creates and cryptographically signs a transaction using a wallet.
2. The transaction is submitted to an Ethereum node and propagated across the peer-to-peer network.
3. Nodes validate its signature, nonce, fee information, and other protocol rules.
4. A validator selects valid transactions and includes them in a proposed block.
5. Other validators attest to valid blocks under Ethereum's Proof-of-Stake consensus mechanism.
6. Every execution node independently runs the transactions through the EVM.
7. The resulting state changes, such as updated balances and contract storage, become part of the blockchain state.
8. Checkpoints eventually achieve finality, making reversal economically and computationally difficult.

Ethereum includes the mainnet for real-value applications and test networks such as Sepolia and Holesky for development and testing.

The Ethereum ecosystem consists of several interconnected components:

• Ether: The native asset used for value transfer, staking, and transaction fees.
• Accounts: Externally owned accounts and contract accounts hold balances and interact with the network.
• Smart contracts: Programs deployed at blockchain addresses and executed by the EVM.
• EVM: The deterministic execution engine that processes smart-contract bytecode.
• Nodes: Computers that verify, store, or provide access to Ethereum data.
• Validators: Participants who stake ETH and help propose and attest to blocks.
• Wallets: Applications that manage keys, sign transactions, and connect users to DApps.
• DApps: Applications combining smart contracts with web or mobile interfaces.
• Development tools: Frameworks such as Hardhat, Foundry, Remix, and libraries such as ethers.js.
• APIs and providers: Interfaces through which software reads blockchain data and submits transactions.
• Supporting protocols: Standards and services such as ERC-20, ERC-721, ENS, IPFS, and Layer-2 networks.

A wallet signs a request, an API submits it to a node, validators include it in a block, and the EVM executes the relevant smart contract. DApps then read the resulting state through the same node infrastructure.

The Ethereum Virtual Machine, or EVM, is the runtime environment used to execute Ethereum smart contracts.

Its important features are:

• Stack-based architecture: The EVM processes bytecode using a stack with 256-bit words.
• Deterministic execution: Given the same initial state and transaction, every node obtains the same result.
• Isolation: Contract code runs in a sandboxed environment and cannot directly access a computer's local files or operating system.
• Bytecode execution: High-level contract languages such as Solidity compile into EVM bytecode.
• State access: Contracts can read and modify account balances, persistent storage, memory, and transaction data.
• Gas metering: Every operation has a gas cost, preventing unbounded computation and compensating the network.
• Reversion: If execution fails or runs out of gas, state changes made by that call are reverted, although consumed gas is not refunded completely.

The EVM is therefore the common computational engine that enables Ethereum nodes to verify smart-contract behavior consistently.

A smart contract is a program stored at an Ethereum address and executed by the EVM when it receives an appropriate transaction or message call.

Life cycle:

1. Developers write the source code, usually in Solidity or Vyper.
2. A compiler generates bytecode and an Application Binary Interface, or ABI.
3. The bytecode is deployed through a contract-creation transaction.
4. The assigned contract address is used by users and other contracts.
5. Function calls read or modify contract state according to the encoded rules.
6. Events may be emitted so that off-chain applications can detect changes.

Benefits:

• Automated and transparent execution
• Reduced dependence on intermediaries
• Composability with other contracts
• Verifiable rules and transaction history

Limitations:

• Deployed code is difficult to modify unless an upgrade mechanism is designed.
• Programming errors can cause permanent financial loss.
• Execution and storage require gas.
• Contracts cannot directly obtain trustworthy external data and therefore need oracles.
• Public blockchain data provides limited privacy.

Smart contracts must therefore be carefully designed, tested, audited, and deployed.

Gas is a unit that measures the computational work required to execute an Ethereum transaction or smart-contract operation.

• Gas used: The actual amount of computational work consumed.
• Gas limit: The maximum gas the sender permits the transaction to consume.
• Base fee: A protocol-determined fee per unit of gas that changes according to network demand and is burned.
• Priority fee: An optional tip paid to the validator to encourage transaction inclusion.
• Maximum fee: The highest amount per gas unit that the sender is willing to pay.

A simplified upper bound for transaction cost is:

The effective cost is based on the actual gas used and the applicable effective gas price. Gas is important because it:

• Prevents infinite loops and denial-of-service computation.
• Allocates scarce block space through market-based fees.
• Compensates validators for transaction processing.
• Encourages developers to write efficient contracts.

If a transaction runs out of gas, its state changes are reverted, but the gas already consumed is still charged.

A typical Ethereum development environment contains tools for writing, compiling, testing, deploying, and interacting with contracts.

• Code editor: Visual Studio Code or another editor is used to write source code.
• Solidity compiler: solc converts Solidity source code into EVM bytecode and an ABI.
• Remix IDE: A browser-based environment for learning, compiling, debugging, and deploying contracts.
• Hardhat: A JavaScript and TypeScript framework offering compilation, testing, local networking, deployment, and debugging.
• Foundry: A fast, Solidity-oriented toolkit containing tools such as Forge, Cast, and Anvil.
• Local blockchain: Hardhat Network, Anvil, or Ganache provides temporary accounts and blocks for development.
• Client library: ethers.js or web3.js connects the application to an Ethereum node.
• Wallet: A wallet such as MetaMask signs deployment and function-call transactions.
• Node provider: A self-hosted node or hosted RPC service gives access to testnets and mainnet.
• Testing tools: Unit tests, fuzz tests, static analysis, and gas reports improve reliability.

Developers normally test locally, deploy to a test network, verify and audit the contract, and only then consider a mainnet deployment.

An Ethereum block packages validated data and links it to an earlier block, thereby creating an ordered blockchain.

A block broadly contains:

• Block header: Metadata used to identify and validate the block.
• Parent hash: A reference to the preceding block.
• State root: A cryptographic commitment to Ethereum's resulting global state.
• Transactions root: A commitment to the transactions included in the block.
• Receipts root: A commitment to transaction outcomes, gas usage, and logs.
• Timestamp and block number: Information identifying the block's position and time.
• Gas limit and gas used: Values controlling and recording total block computation.
• Base fee: The protocol fee per gas unit for the block.
• Validator-related data: Information associated with block proposal under Proof of Stake.

Each valid block references its parent. Changing an old block would alter its cryptographic commitments and conflict with later blocks and consensus. Transactions in a block are executed in order, and the final result produces a new state root. Blocks thus provide an auditable history of transitions from one Ethereum state to the next.

Ethereum has two principal account categories:

An externally owned account can send ETH or invoke a contract by signing a transaction. A contract account executes its programmed logic when called. Both account types have Ethereum addresses and can hold ETH, but a contract does not independently sign transactions with a private key.

An Ethereum wallet is a tool that manages account keys, creates signatures, displays balances, and connects users to blockchain applications. ETH itself remains recorded on the blockchain; the wallet controls the credentials needed to authorize actions.

• Custodial wallet: A service provider controls the private keys. It is convenient and may offer account recovery, but users depend on the provider's security and policies.
• Non-custodial wallet: The user controls the private keys or recovery phrase. It provides greater control but makes the user responsible for backup and protection.
• Software wallet: Keys are managed by a browser extension, desktop program, or mobile application. It is convenient for frequent DApp use but may be exposed to malware or phishing.
• Hardware wallet: Private keys are isolated in a dedicated physical device, and transactions are confirmed on that device. It offers stronger protection for valuable accounts.

Important wallet practices include protecting the recovery phrase, verifying addresses and contract permissions, using hardware signing where appropriate, avoiding unknown links, and never sharing private keys.

The terms describe different network roles:

• Full node: Verifies blocks and transactions and maintains enough current state and blockchain data to enforce protocol rules independently.
• Archive node: Stores historical states in addition to normal node data. It supports detailed historical queries but requires substantially more storage.
• Light client: Downloads and verifies limited data, relying on cryptographic proofs and full nodes for additional information. It uses fewer resources.
• Validator: In modern Proof-of-Stake Ethereum, a validator stakes ETH, proposes blocks when selected, and attests to blocks proposed by others.
• Miner: Under Ethereum's former Proof-of-Work model, miners competed using computational power to create blocks. Mainnet mining ended with The Merge in September 2022.

A modern Ethereum node commonly uses two client layers:

• An execution client, such as Geth, executes transactions and maintains EVM state.
• A consensus client participates in Proof-of-Stake consensus.

Running a node does not automatically make it a validator; validation additionally requires staking, validator software, and secure key management.

Ethereum APIs allow wallets, scripts, and DApps to communicate with nodes. The most common interface is JSON-RPC, transported through HTTP, WebSocket, or inter-process communication.

Important methods include:

• eth_blockNumber: Returns the latest known block number.
• eth_getBalance: Reads an account's ETH balance at a selected block.
• eth_getTransactionByHash: Retrieves transaction information.
• eth_getTransactionReceipt: Returns status, gas usage, and emitted logs after execution.
• eth_call: Simulates a read-only contract call without creating a blockchain transaction.
• eth_estimateGas: Estimates the gas required for a proposed operation.
• eth_sendRawTransaction: Submits a locally signed transaction.
• eth_getLogs: Retrieves event logs matching specified filters.
• eth_getCode: Returns the bytecode stored at an address.

DApps generally use libraries such as ethers.js to encode function calls, invoke these methods, decode responses, and monitor events. Public RPC endpoints should be rate-limited and protected because exposing administrative or account-management APIs can create serious security risks.

A decentralized application, or DApp, is an application whose critical rules or state are managed by smart contracts on a decentralized network.

A typical DApp architecture includes:

• Front end: A web or mobile interface built using conventional technologies.
• Wallet connector: Requests account access and signatures from a user's wallet.
• Provider or client library: ethers.js, web3.js, or a similar library communicates with an Ethereum RPC endpoint.
• Smart contracts: Implement the trusted application logic and maintain on-chain state.
• Off-chain storage: IPFS or another system may store large files or metadata.
• Indexer: Services can organize blockchain events for efficient searching and display.
• Oracle: Supplies external information when contract logic requires real-world data.

Transaction flow:

1. The user chooses an action in the interface.
2. The DApp encodes the appropriate contract function call.
3. The wallet displays the request and asks the user to sign it.
4. The signed transaction is sent to a node.
5. A validator includes it in a block, and the EVM executes the contract.
6. The interface obtains the receipt or detects emitted events and updates its display.

The front end may be centralized, but the contract logic remains independently verifiable on Ethereum.

Ethereum tools support the complete application life cycle:

• Remix: Browser-based Solidity editor, compiler, debugger, and deployment interface.
• Hardhat: Provides compilation, scripted deployment, automated tests, network simulation, and stack traces.
• Foundry: Offers fast contract compilation, Solidity-based tests, fuzzing, scripting, and local-node facilities.
• Anvil or Ganache: Runs a local development blockchain with test accounts and configurable state.
• ethers.js or web3.js: Allows JavaScript applications to connect to providers, encode calls, sign data, and interact with contracts.
• OpenZeppelin Contracts: Supplies reviewed implementations of common token, access-control, and security patterns.
• Slither: Performs static analysis to detect possible contract vulnerabilities.
• Echidna: Uses property-based fuzzing to discover unexpected behavior.
• Geth: Runs an Ethereum execution node and exposes RPC and console interfaces.
• Block explorers: Etherscan and similar services display blocks, accounts, transactions, verified code, events, and token activity.

No single tool guarantees security. Reliable development combines unit tests, integration tests, fuzzing, static analysis, code review, testnet deployment, and professional auditing where necessary.

Supporting protocols and standards extend Ethereum's basic smart-contract platform:

• ERC-20: Defines a common interface for fungible tokens, including transfers, balances, and allowances.
• ERC-721: Defines non-fungible tokens in which each token has a unique identifier.
• ERC-1155: Supports multiple fungible and non-fungible token types within one contract.
• ENS: The Ethereum Name Service maps readable names to addresses and other records.
• IPFS: A content-addressed peer-to-peer storage system often used for DApp files and token metadata.
• Oracles: Deliver external information, such as asset prices or weather data, to smart contracts.
• Layer-2 networks: Process transactions beyond Ethereum's base layer and submit data or proofs back to it, improving throughput and reducing user fees.
• Wallet connection protocols: Standardize communication between wallets and DApps across devices.

These systems improve interoperability, scalability, usability, storage, and access to external information. However, each may introduce additional trust assumptions, smart-contract risks, or data-availability considerations that developers must evaluate.

Different languages are used at different layers of Ethereum development:

• Solidity: The most widely used high-level smart-contract language. It supports inheritance, libraries, interfaces, modifiers, events, and complex user-defined types. It compiles to EVM bytecode.
• Vyper: A Python-like smart-contract language that emphasizes simplicity, auditability, and restricted language features. It also compiles to EVM bytecode.
• JavaScript or TypeScript: Commonly used for DApp front ends, deployment scripts, automated tests, and interaction through ethers.js or web3.js. These languages normally run off-chain.
• Go: Used to build blockchain infrastructure and backend services. Geth, a major Ethereum execution client, is implemented in Go.

Solidity and Vyper define on-chain behavior, where execution costs gas and must be deterministic. JavaScript, TypeScript, and Go usually implement off-chain components, where applications communicate with nodes through APIs. Language choice depends on security requirements, ecosystem support, performance, and the component being developed.

A secure contract deployment process includes the following stages:

1. Write the source code: Define state variables, functions, events, access controls, and error handling.
2. Compile: Use a suitable compiler version to produce deployment bytecode, runtime bytecode, and the ABI.
3. Test locally: Run unit, integration, edge-case, and failure-condition tests on a local blockchain.
4. Analyze security: Use static analysis, fuzzing, code review, and auditing where appropriate.
5. Configure deployment: Choose the network, RPC endpoint, deployer account, constructor arguments, and fee settings.
6. Estimate gas: Ensure that the deployer has enough test ETH or real ETH for deployment.
7. Sign and submit: The deployment transaction contains contract-creation data rather than an ordinary recipient call.
8. Wait for inclusion: After the transaction is included, the receipt provides the contract address and deployment status.
9. Verify behavior: Call read-only functions and perform controlled state-changing tests.
10. Verify source code: Publish the exact compiler settings, source code, and constructor arguments on a block explorer.
11. Record deployment data: Save the address, ABI, transaction hash, network identifier, and release version.

For mainnet, private keys should be securely managed, administrator privileges minimized, and any upgrade mechanism clearly documented.

These elements connect smart contracts with external applications:

• ABI: A JSON description of a contract's functions, parameters, return values, events, and errors. Libraries use it to encode function calls and decode returned data.
• Creation bytecode: Code sent in a deployment transaction. It executes the constructor and returns the contract's runtime bytecode.
• Runtime bytecode: The EVM instructions stored at the contract address and executed on later calls.
• Events: Contract statements that write structured entries to transaction logs. DApps and indexers can efficiently monitor these logs.
• Transaction receipt: A record produced after a transaction is included in a block. It contains information such as success or failure status, gas used, contract address for deployment, and emitted logs.

The ABI is not itself executable code. It acts as a translation specification between human-readable function calls and EVM-encoded data. Events are suitable for off-chain observation but cannot be read by contracts as persistent storage during later transactions.

Geth, or Go Ethereum, is an Ethereum execution client. It can synchronize blockchain data, validate execution-layer rules, expose JSON-RPC APIs, and provide an interactive JavaScript console.

A typical exploration procedure is:

1. Install Geth from a trusted source and verify the package where possible.
2. Start Geth on the desired network with an appropriate data directory.
3. Allow the execution client to synchronize; a Proof-of-Stake node also requires connection to a consensus client for full operation.
4. Open a console by starting Geth with console or attaching with geth attach to an existing node.
5. Use console objects such as eth, net, and web3 to inspect the node.

Example operations include:

• eth.blockNumber to inspect the latest known block number.
• net.peerCount to check connected peers.
• eth.syncing to view synchronization status.
• eth.getBalance(address) to read an account balance in wei.
• eth.getBlock("latest") to inspect the latest block.
• eth.getTransaction(txHash) to retrieve transaction details.
• eth.getTransactionReceipt(txHash) to inspect the execution result.

The available methods depend on enabled modules and Geth version. Sensitive APIs should never be exposed to untrusted networks.

Geth can expose Ethereum's JSON-RPC interface through IPC, HTTP, or WebSocket. Web3 libraries use this interface to connect an application to the network.

Reading contract state:

• The application creates a provider connected to Geth.
• It loads the contract address and ABI.
• A read-only function is encoded and sent through eth_call.
• Geth executes the call locally against the selected block state without creating a transaction or changing state.

Submitting a transaction:

1. The application encodes the contract function and arguments.
2. It obtains the sender's nonce and estimates gas.
3. A wallet or secure signer signs the transaction locally.
4. The signed transaction is submitted using eth_sendRawTransaction.
5. Geth propagates it to peers.
6. The application polls for a receipt or subscribes for updates.

Monitoring events:

• Applications can query historical logs using eth_getLogs.
• A WebSocket connection can provide subscriptions for new blocks or matching logs.
• The ABI is used to decode indexed topics and event data.

Security precautions:

• Prefer IPC for trusted local administration.
• Bind HTTP and WebSocket interfaces only to necessary network addresses.
• Enable only required RPC namespaces.
• Do not expose administrative, debugging, or account-management interfaces publicly.
• Keep private keys in a wallet, hardware device, or secure signer rather than in application source code.
• Validate chain identifiers, contract addresses, transaction data, and user-visible signing requests.

This separation allows Geth to provide blockchain access while the wallet retains responsibility for secure transaction authorization.