Smart Contracts and Ethereum Flashcards

In Ethereum's EVM, what happens when a smart contract's `SELFDESTRUCT` opcode is called and the target recipient address is the contract itself?

Answer: The ETH is transferred to the contract address and remains locked forever since the contract no longer has code to send it out

When SELFDESTRUCT specifies the contract's own address as the recipient, the ETH is sent there — but since the contract's code and storage are wiped in the same operation, there is no longer any function to retrieve or move that ETH. The funds become permanently inaccessible, effectively burned, even though they still appear at that address on-chain.

A Solidity contract uses `tx.origin` for access control instead of `msg.sender`. Which specific attack vector does this introduce that `msg.sender` would prevent?

Answer: Phishing via a malicious intermediary contract tricking the original EOA into authorizing calls

`tx.origin` always refers to the original externally-owned account (EOA) that initiated the transaction chain, not the immediate caller. An attacker can deploy a malicious contract that a victim calls (e.g., to claim a reward), and that malicious contract in turn calls the victim's protected contract. Because `tx.origin` is the victim's EOA, the access control passes — granting the attacker unauthorized access. `msg.sender` would correctly identify the malicious contract as the caller and block it.

Ethereum's EIP-1559 introduced a base fee that is algorithmically adjusted per block. What happens to this base fee ETH?

Answer: It is permanently burned, removing it from the total ETH supply

Under EIP-1559 (activated in the London hard fork), the base fee paid by every transaction is burned — permanently removed from the circulating ETH supply. Only the priority fee (tip) goes to the block validator. This deflationary mechanism means that during periods of high network usage, ETH issuance from staking rewards can be outpaced by burns, making ETH net-deflationary.

A proxy contract pattern using `delegatecall` stores its implementation address in a specific storage slot defined by EIP-1967 rather than slot 0. What is the primary reason for this design choice?

Answer: Using slot 0 would collide with the first state variable declared in the implementation contract's storage layout

When a proxy uses `delegatecall`, the implementation contract's code executes in the context of the proxy's storage. If the proxy stores the implementation address in slot 0, it will collide with whatever the implementation contract declares as its first state variable — silently overwriting it or being overwritten. EIP-1967 uses pseudo-random slots derived from keccak256 of a well-known string (minus 1) that are astronomically unlikely to collide with any normal contract storage layout.

Which of the following correctly describes the behavior of Ethereum's `CREATE2` opcode compared to `CREATE`?

Answer: CREATE2 allows deploying a contract to a deterministic address computed from the deployer, a salt, and the init bytecode hash — enabling counterfactual instantiation

CREATE2 computes the deployment address as `keccak256(0xFF ++ deployerAddress ++ salt ++ keccak256(initBytecode))`. Because the address is deterministic and known before deployment, protocols can reference a contract's address (e.g., in payment channels or L2 state channels) before it's actually deployed — this is called counterfactual instantiation. Note: while a contract can self-destruct and be redeployed with CREATE2 using the same salt, the new deployment must use the same init bytecode; it doesn't allow arbitrary code swaps.

In the context of Ethereum smart contract security, what is a 'read-only reentrancy' vulnerability?

Answer: A vulnerability where a contract's internal state is inconsistent mid-execution, and a malicious contract exploits this by calling a view function on it from within a callback to obtain a manipulated price or balance reading

Read-only reentrancy occurs when Contract A calls Contract B (e.g., via an ETH transfer hook), and during that callback, Contract B calls a `view` function on Contract A. Because Contract A's state is mid-update (e.g., collateral removed but shares not yet burned), the view function returns an inconsistent/manipulated value. If a third protocol (Contract C) relies on that view function for pricing or collateralization checks, Contract B can exploit the window to manipulate C's calculations. Classic CEI (Checks-Effects-Interactions) prevents classic reentrancy but doesn't protect downstream consumers of view functions.