Unit 5 - Practice Quiz

While Ethereum has its own cryptocurrency (Ether), its main innovation is being a programmable blockchain that allows developers to create and deploy decentralized applications (dApps) and smart contracts.

A smart contract is self-executing code stored on the blockchain. It runs when predetermined conditions are met, without the need for a central authority or intermediary.

Ether (ETH) is the native digital currency used to power the Ethereum network, pay for transaction fees (gas), and reward miners/validators.

Gas is the fee required to successfully conduct a transaction or execute a contract on the Ethereum blockchain. It measures the amount of computational work required for the operation.

Turing completeness means the language is computationally universal. It can be used to simulate any Turing machine, which implies it can perform any computation that any other general-purpose computer can.

Because a Turing-complete language can express complex logic, including loops, it's possible to write a contract that never terminates. On Ethereum, this would cause the contract to run until it runs out of gas, failing the transaction.

The Halting Problem is a famous undecidable problem. It's impossible to create a single algorithm that can analyze any arbitrary program and determine if it will eventually halt or enter an infinite loop. This has implications for automatically detecting all such bugs in smart contracts.

Formal verification uses rigorous mathematical methods to check the correctness of code against a formal specification. Given the immutable and high-stakes nature of smart contracts, this is crucial for ensuring security.

'Code is law' suggests that the rules embedded in a smart contract's code are the final arbiters of the agreement, and the contract will execute exactly as written.

Blockchains are deterministic systems and cannot access outside information on their own. Oracles are services that act as a bridge, feeding external data (like weather or price feeds) onto the blockchain for smart contracts to use.

Smart contracts can automate the function of an escrow agent. Funds are held and released automatically based on coded conditions, removing the need to trust and pay a human intermediary.

Legal agreements often rely on interpretation and context. Computer code, by contrast, must be completely explicit and unambiguous, making it difficult to capture the nuances of legal prose.

To maximize security and predictability while minimizing attack surfaces, Bitcoin's scripting language was designed to be non-Turing-complete. It lacks features like complex loops, which prevents many of the complex applications possible on Ethereum.

A DAO requires complex, stateful logic for voting, proposals, and treasury management. This level of complexity is well-suited for Ethereum's Turing-complete smart contracts but is beyond the capabilities of Bitcoin's simple, non-Turing-complete script.

The EVM is the part of Ethereum that handles smart contract execution. It's a quasi-Turing-complete, isolated environment that ensures contract code cannot interfere with the rest of the network.

Bitcoin tracks ownership through a ledger of UTXOs, which are like individual pieces of digital cash. Ethereum uses an account model, similar to a bank account, where each account has a balance that is directly debited or credited.

Solidity is a contract-oriented, high-level programming language specifically created for implementing smart contracts on platforms like Ethereum. Its syntax is influenced by C++, Python, and JavaScript.

Declaring a state variable as public in Solidity instructs the compiler to generate a function that allows other contracts and external accounts to read its value without needing to write the function manually.

Ethers.js and Web3.js are comprehensive JavaScript libraries that provide the necessary tools to connect to an Ethereum node (e.g., through MetaMask) and interact with deployed smart contracts from a front-end application.

The constructor is an optional, special function that runs only during the creation of the contract. It is typically used to initialize state variables, such as setting the owner (msg.sender) of the contract.

Smart contracts on Ethereum are immutable, meaning their code cannot be changed once deployed. The standard practice for 'updating' a contract is to deploy a new, corrected version. This often involves using a proxy pattern where a stable proxy contract points to the address of the latest implementation contract, allowing for upgrades without changing the address users interact with. Directly editing code is impossible.

Both view and pure functions do not modify the blockchain state. The distinction is that view functions can read state variables (e.g., balances, stored values). In contrast, pure functions are more restrictive; they cannot read or write to the state and only operate on their input parameters and local variables (e.g., performing a mathematical calculation). Calling either externally via a node does not cost gas as it doesn't create a transaction.

A DAO requires complex, stateful logic: tracking membership, proposal details, voting status, and treasury management. This relies on Ethereum's Turing-complete nature and its account-based state model. Bitcoin Script is intentionally non-Turing-complete and primarily designed for transaction validation. While it can handle multi-sig and timelocks, it lacks the ability to manage the complex, persistent state and arbitrary logic required for a DAO.

The Halting Problem states that it is impossible to create a general algorithm that can determine whether any given program will finish running or continue to run forever. Since Solidity is Turing-complete, a malicious or poorly written contract could contain an infinite loop. The gas mechanism solves this by attaching a cost to every computational step. A transaction with an infinite loop will eventually run out of gas, halt its execution, and revert, preventing it from freezing the entire network.

Blockchains and smart contracts are deterministic systems that cannot natively access external, off-chain data like weather information, stock prices, or sports results. An oracle is a trusted third-party service that fetches and verifies external information and pushes it onto the blockchain for smart contracts to use. In a crop insurance contract, an oracle would provide rainfall data, allowing the smart contract to automatically trigger a payout if a drought condition is met.

Events are a core feature of Solidity designed for this purpose. Emitting an event is a low-cost way to log data on the blockchain that is not directly accessible by other smart contracts but can be efficiently read by external clients (like a JavaScript frontend using web3.js or ethers.js). This is much more efficient than storing data in contract storage or creating new transactions for notification purposes.

This is a fundamental difference. Ethereum's 'world state' is like a global database where each address has an associated account with a balance, nonce, code, and storage. This makes it easy for smart contracts to manage and persist their own internal state. Bitcoin's state is a collection of UTXOs. A transaction consumes existing UTXOs and creates new ones. This model is simpler and excellent for payments but less suited for complex applications that require a persistent, shared state.

A re-entrancy attack occurs when an external contract call is made before updating the internal state (like a user's balance). The malicious external contract can then call back into the original function before the state update occurs, allowing it to drain funds repeatedly. The recommended 'Checks-Effects-Interactions' pattern, where internal state is updated before the external call, is the primary defense against this.

The EVM is the core of Ethereum's smart contract execution. It is a quasi-Turing-complete state machine. When a transaction calls a smart contract, every full node on the network runs the contract's bytecode within its local EVM instance. The EVM's strict, deterministic rules ensure that every node computes the same result and arrives at the same final state, which is essential for maintaining consensus.

Smart contracts excel at executing objective, binary logic. Terms like 'satisfactory condition', 'reasonable effort', or 'good faith' are subjective and cannot be algorithmically determined by the contract itself. Implementing such a clause would require an oracle or a mutually trusted third party (an arbitrator) to evaluate the condition and report the binary outcome (satisfactory/not satisfactory) to the contract.

When a transaction runs out of gas, it triggers an 'out-of-gas' exception. The EVM halts execution and reverts any changes made to the state during that transaction's execution. However, the computational work has already been done by the validating nodes. Therefore, the sender forfeits the entire gas fee up to the gas limit to compensate the miner for their work. This prevents denial-of-service attacks where users could submit complex, non-terminating transactions without penalty.

The public keyword automatically generates a getter function that other contracts or external clients can call. For dynamic arrays, this getter function returns the entire array. If the array grows to be very large, the gas cost of copying the entire array into memory and returning it can exceed the block gas limit, making it impossible for other contracts to call this getter and causing transactions to fail.

Formal verification uses rigorous mathematical methods to prove or disprove the correctness of a system with respect to a formal specification. For smart contracts, this means proving properties like 'the total supply of this token can never exceed X' or 'only the owner can withdraw funds'. It is a powerful but complex technique that provides a much higher level of assurance than traditional testing, which can only show the presence of bugs, not their absence.

In Bitcoin, block space is the scarce resource, so fees (satoshis/byte) are based on the data size of the transaction. In Ethereum, both block space and computational effort are scarce resources. The gas system prices every single operation (e.g., addition, storage write), so a computationally intensive transaction will cost more than a simple transfer, even if they are the same size in bytes. The total fee in Ethereum is gas used * gas price.

The 'Code is Law' philosophy posits that a smart contract's code is the ultimate arbiter. However, this becomes problematic when the code contains a bug or is exploited in a way that the human parties did not intend (e.g., the DAO hack). In such cases, the code's execution might be valid according to the EVM's rules, but it violates the spirit and intent of the underlying agreement, creating a conflict that traditional legal systems are designed to resolve through interpretation and context.

This is a core distinction in Ethereum's account model. EOAs are the 'user' accounts, controlled by a private key that allows them to sign and initiate transactions. Contract Accounts do not have private keys; their behavior is dictated entirely by the code deployed at their address. A Contract Account can react to transactions (by running its code) and call other contracts, but it can never start a new transaction on its own. All activity on Ethereum must originate from an EOA.

Solidity has four visibility modifiers: public (callable by anyone), external (callable only from other contracts and EOAs), internal (callable from the contract and derived contracts), and private (callable only from the contract in which it is defined). internal is similar to protected in some object-oriented languages and is used for helper functions that are part of the contract's internal logic but not its public interface.

Bitcoin's design prioritizes security and predictability for its primary use case: a peer-to-peer electronic cash system. A non-Turing-complete language, which lacks features like complex loops and recursion, has a much smaller attack surface. It makes it possible to analyze a script and predict its resource consumption and outcome with certainty, which is a crucial security feature for a system handling large amounts of value.

In early versions of Solidity (before 0.8.0), arithmetic operations on fixed-size integers did not check for overflow or underflow. For example, if a uint8 (max value 255) holding the value 255 was incremented, it would 'wrap around' to 0. This could be exploited, for instance, in a token contract to create an infinite balance. Modern Solidity versions (0.8.0+) automatically revert on overflow/underflow, but safe math libraries were required to mitigate this in older contracts.

Calls to view or pure functions do not modify the blockchain state. Therefore, they don't need to be packaged into a transaction, broadcast to the network, and mined. When a DApp makes such a call, the connected node simply runs the function's bytecode against its current view of the state and returns the output. This is a read operation, and because it doesn't change anything, it is free (no gas) and instantaneous.

delegatecall executes the code of the implementation contract within the context (storage, msg.sender, etc.) of the proxy contract. State variables in Solidity are assigned storage slots sequentially, starting from slot 0. In V1, value is at slot 0. In V2, owner is at slot 0. When the proxy, which has its own storage layout based on V1, calls V2, the V2 code that writes to owner (slot 0) will write to the proxy's slot 0. This overwrites the value variable with the 20-byte address data (padded to 32 bytes). This is a critical vulnerability known as a storage collision in upgradeable contracts, which must be prevented by following specific storage layout patterns like the Unstructured Storage Pattern.

The gas system is Ethereum's practical solution to the Halting Problem. While it cannot solve the problem in the theoretical computer science sense (it can't predict halting beforehand), it makes infinite loops economically impossible. Each operation (opcode) consumes a specific amount of gas. A transaction is submitted with a finite gasLimit. If the execution consumes all the available gas before completion, it triggers an out-of-gas exception, reverts all state changes, and terminates. This prevents a single malicious or buggy contract from halting the entire network.

DeFi applications like DEXs rely on a central pool of logic and state that many users can interact with concurrently. Ethereum's smart contracts act as stateful objects, making it easy to model a liquidity pool or an order book as a single entity. In Bitcoin's UTXO model, there is no concept of a shared state account. To simulate it, the entire state of the DEX would have to be encoded into a single UTXO, which is then spent and recreated in every single trade. This creates a bottleneck, as only one state change can be processed at a time, making it impractical for high-frequency, multi-user applications.

This question highlights the gap between deterministic code and ambiguous legal language. Smart contracts can only operate on data available on the blockchain. The concept of "delivery" requires an oracle to feed external data (e.g., from a GPS tracker or shipping company API) onto the chain. More challenging is the term "satisfactory condition," which is subjective and requires human judgment. A smart contract cannot make such a judgment call. This necessitates either a trusted third-party oracle that attests to the condition, or a complex system for decentralized dispute resolution (like Kleros), which reintroduces layers of human trust and interaction that pure smart contracts aim to eliminate.

The key innovation of CREATE2 is that it makes contract deployment addresses deterministic and independent of the deployer's nonce. The address is calculated from a hash of the deployer's address, a salt (a user-chosen number), and the hash of the contract's creation bytecode. This means anyone can calculate the address where a specific contract will be deployed without it actually being deployed yet. This allows for powerful patterns like state channels, where an on-chain escrow/judge contract address is agreed upon, and funds can be sent there, but the contract itself is only deployed if a dispute arises, saving significant gas costs.

This is a classic vulnerability. If a wallet contract authorizes actions based on tx.origin, an attacker can write a simple contract that calls the wallet's vulnerable function. The attacker then tricks the legitimate owner into calling any function on this malicious contract. When the owner does so, the transaction flow is: Owner EOA -> Malicious Contract -> Wallet Contract. Within the wallet's function, msg.sender is the address of the Malicious Contract, but tx.origin is the address of the Owner EOA. The authorization check passes, allowing the malicious contract's code to execute with the owner's privileges, potentially draining all funds.

Rice's Theorem is a generalization of the Halting Problem. A 'non-trivial semantic property' is any property about the program's behavior or function (e.g., 'does this function ever return zero?', 'is this contract vulnerable to a flash loan attack?'). The theorem states that no algorithm can exist that can correctly decide such properties for all possible input programs (smart contracts). This means that while security analysis tools can find specific, known patterns of bugs, they can never be perfect. There will always be smart contracts for which the tool will either fail to terminate, give a wrong answer, or report that it cannot decide.

The 2300 gas stipend was an early, protocol-level defense against reentrancy vulnerabilities. A typical reentrancy attack involves the recipient contract calling back into the original caller before the original function has finished its state updates. An external call costs a minimum of 700 gas, and any storage write costs much more. The 2300 gas stipend is intentionally too small to allow the recipient to make another external call or perform significant state changes. It is generally only enough to log an event. This breaks the attack pattern. While the modern best practice is the Checks-Effects-Interactions pattern, the gas stipend serves as a historical and partial safeguard.

The key is in the name: ecrecover performs elliptic curve signature recovery. This means a smart contract can be given a message and a signature, and the function will return the address of the account that produced that signature. This is the foundation of meta-transactions. A user can sign a message off-chain, and a third-party 'relayer' can submit it to a contract. The contract uses ecrecover to verify that the message was indeed signed by the user, and then executes the action on their behalf. OP_CHECKSIG cannot do this; it can only confirm true or false if a provided signature matches a provided public key, it cannot determine the signer's identity from the signature alone.

In Solidity, a dynamic bytes array in memory has a specific layout. The first 32-byte word (at the pointer b) stores the length of the array (in this case, 64). The actual data starts at the memory location add(b, 0x20). The mstore opcode writes a 32-byte (256-bit) word. The first mstore writes 0xFF (as a 32-byte word) to the start of the data section. The second mstore writes 0xEE to the memory location 32 bytes after the start of the data section (add(b, 0x40)). Therefore, the returned 64-byte array will consist of the 32-byte representation of 0xFF followed by the 32-byte representation of 0xEE.

The core concept of a Ricardian Contract is the tight, verifiable binding of legal prose and executable code. It aims to prevent ambiguity by ensuring that the contract executed by the machine is irrefutably linked to the text agreed upon by the humans. A typical Ethereum smart contract setup has the code on-chain and a PDF agreement stored elsewhere. There is no cryptographic guarantee that the PDF and the code represent the same agreement. A Ricardian contract model would, for example, embed the hash of the legal PDF within the smart contract's state, creating an unbreakable link and ensuring that what you read is what you execute.

This vulnerability arises because the computational cost (and thus gas cost) of the function is determined by an external input (items.length). An attacker can craft a transaction that calls process with an array so large that its execution would require more gas than the block gas limit allows. The transaction will always revert. If other functions in the contract depend on process being successfully run (e.g., a function to pay out dividends that first processes all contributions), the attacker can render that functionality unusable for everyone, effectively bricking that part of the contract at a very low cost to themselves.

This describes how to replace a pending transaction on Ethereum. A transaction is uniquely identified by the sender's address and its nonce. Only one transaction per nonce can be confirmed for any given account. When multiple transactions with the same address and nonce are in the mempool, they are in competition. Since miners are economically rational, they will almost always pick the transaction that offers a higher fee (in this case, the one with 30 Gwei gasPrice). Once this higher-fee transaction is mined, the other transaction with the same nonce is rendered invalid and is purged from the network.

The older eth_sign method required users to sign an opaque 32-byte hash, e.g., 0x1c8aff95.... It was impossible for the user to know what they were actually signing. Furthermore, a malicious DApp could craft a message that produced the same hash as a legitimate action on a different, vulnerable DApp, and trick the user into signing it. EIP-712 solves this by defining a standard for hashing structured data. The data is presented to the user in a readable format, and the final hash includes a domainSeparator (containing the DApp's name, version, contract address, etc.). This makes the signature unique to that specific DApp and intended action, preventing cross-application replay attacks.

The primary reason Bitcoin Script is not Turing-complete is the intentional omission of backward jumps or looping instructions. The script is executed sequentially from top to bottom. While it has conditional statements (OP_IF/OP_ENDIF) that allow it to skip sections of code (forward jumps), there is no opcode that allows the instruction pointer to move to a previous point in the script. This structural limitation guarantees that every script will terminate after executing a finite number of opcodes, thus completely avoiding the Halting Problem and the need for a gas-like metering system.

Solidity packs state variables from right to left (less significant bytes to more significant bytes) within a storage slot. The first variable declared, a, will occupy the lower-order 16 bytes (128 bits) of slot 0. The second variable, b, will occupy the higher-order 16 bytes. type(uint128).max is 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF. 1 is 0x01. So, a's value is placed in the right half of the 32-byte word, and b's value is placed in the left half. The resulting 32-byte value in slot 0 is the concatenation of b's 16-byte representation and a's 16-byte representation.

The 'code is law' absolutism is often impractical. A sophisticated solution is to build an 'appeal' mechanism directly into the system's logic. By designating a decentralized arbitration service as the arbiter for certain disputes, the DAO can remain trust-minimized while still having an outlet for complex, unforeseen situations. The smart contract would have a function that can only be called by the arbitration contract. If the decentralized court rules in a particular way, it can call this function to enforce its ruling on-chain. This creates a 'decentralized rule of law' that respects both the automated nature of the code and the need for human judgment in exceptional cases.

This is a very common and critical error for new Web3 developers. JavaScript's native Number type is a 64-bit floating-point number and cannot safely represent integers larger than Number.MAX_SAFE_INTEGER (which is ). The value 100 * 10^{18} is far larger than this. Libraries like ethers.js and web3.js return large integer values as BigNumber objects to preserve their precision. Any attempt to use standard arithmetic operators (+, -, *, /) on these objects directly with JavaScript Numbers will lead to incorrect results. The correct way is to use the methods provided by the BigNumber library itself, such as balance.div(2).

The 'state' of the Bitcoin ledger is the set of all UTXOs. A Bitcoin script's only job is to return true or false to validate the spending of specific UTXOs. The script itself cannot read the state of other UTXOs or write to a persistent database. Its execution context is ephemeral. In contrast, an Ethereum smart contract is like an object with its own internal, persistent storage. A function call can read data that was stored by a previous transaction and can write new data that will persist for future transactions to read. This ability to maintain and modify a persistent, address-specific state is what allows for complex applications like DAOs, ENS, and DeFi protocols.

This is a crucial distinction. When Contract A calls Contract B, the execution inside B has msg.sender as A, and any storage writes affect B's storage. When A delegatecalls B, B's code is executed as if it were A's code. This means msg.sender and msg.value remain the same as in A's original call, and crucially, any storage writes modify A's storage. This is powerful for proxies and libraries but dangerous if not handled correctly. staticcall is like call, but it is guaranteed to be read-only; the EVM will revert the transaction if any opcode that modifies state (like SSTORE, LOG, etc.) is used during a staticcall.