Smart Contracts and Ethereum Flashcards

A smart contract on Ethereum calls an external contract using a low-level `call()` with a fixed gas stipend of 2,300. Which of the following operations will the receiving contract be UNABLE to perform within that stipend?

Answer: Increment a state variable and write it back via SSTORE

The EIP-1884 repricing increased SLOAD to 2,100 gas and a cold SSTORE costs at minimum 2,900 gas (EIP-2929 cold storage write). A 2,300 gas stipend — historically used by Ethereum's transfer() — is deliberately insufficient for any state-modifying operation like SSTORE, preventing reentrancy attacks that write state. Emitting a simple event (~375 gas), reading storage after paying the cold access fee partially, or pure arithmetic can fit or partially execute, but a full cold SSTORE cannot complete.

In the context of Ethereum's EVM, what is the primary purpose of the RETURNDATACOPY opcode introduced in EIP-211?

Answer: To enable contracts to read return data from a previous external call regardless of its size

Before EIP-211 (Metropolis/Byzantium), contracts could only retrieve fixed-size return data using MLOAD after an external call. RETURNDATACOPY (and its companion RETURNDATASIZE) allow a caller to access the full, dynamically-sized return buffer from the most recent external call, enabling safe ABI-decoded responses of arbitrary length. This was critical for safely handling dynamic types like bytes and strings returned from other contracts.

A developer deploys a proxy contract using the EIP-1967 transparent proxy pattern. Which storage slot does EIP-1967 reserve for storing the implementation contract address, and why was that specific slot chosen?

Answer: A pseudo-random slot derived from keccak256('eip1967.proxy.implementation') minus 1, to avoid colliding with normal storage layout

EIP-1967 defines specific storage slots using keccak256 of a well-known string minus 1 (e.g., bytes32(uint256(keccak256('eip1967.proxy.implementation')) - 1)). Subtracting 1 from the hash ensures the slot has no known preimage, making it cryptographically collision-resistant against Solidity's sequential storage layout (slots 0, 1, 2…) and mapping/array slots. This prevents the implementation or admin address from accidentally overlapping with the logic contract's own state variables.

When Ethereum's Merge transitioned the network from Proof-of-Work to Proof-of-Stake, which smart contract opcode became permanently deprecated and always returns zero, because the underlying mechanism it referenced no longer exists?

Answer: DIFFICULTY (now PREVRANDAO)

Post-Merge, the DIFFICULTY opcode (0x44) was repurposed via EIP-4399 to return PREVRANDAO — the previous beacon chain randomness value — rather than returning zero. However, contracts that relied on DIFFICULTY for proof-of-work mining difficulty checks receive semantically different data now. While the opcode still executes (returning PREVRANDAO), its original semantic meaning is permanently gone. Importantly, contracts using DIFFICULTY as a weak randomness source are now exposed to validator influence over PREVRANDAO, changing the security model entirely. BLOCKHASH, COINBASE, and GASLIMIT all retained their functional meanings post-Merge.

A flash loan arbitrage smart contract borrows 1,000 ETH from a lending protocol and must repay it within the same transaction. The contract's arbitrage logic unexpectedly causes a revert mid-execution. What is the net effect on the lending protocol's reserves?

Answer: The protocol retains all 1,000 ETH because the entire transaction reverts atomically, including the loan disbursement

Ethereum transactions are atomic: if any operation within a transaction reverts, all state changes from that transaction — including the initial transfer of 1,000 ETH from the protocol to the borrower — are rolled back entirely. Flash loans exploit this atomicity by design: the loan, its use, and its repayment must all succeed within one transaction, or nothing happens. Gas fees are still paid by the transaction sender (from their existing ETH balance) because gas consumption is not a state change subject to revert, but the lending protocol's reserves are completely unaffected.

In Solidity, a contract marked `abstract` contains an unimplemented function `function computeFee(uint256 amount) external virtual returns (uint256);`. A child contract inherits from it but also declares itself `abstract` without implementing `computeFee`. What happens when a third contract attempts to directly deploy the child contract?

Answer: The compiler rejects the child contract at compile time unless it implements all inherited virtual functions or is also marked abstract

Solidity enforces at compile time that any contract with unimplemented virtual functions must be declared `abstract` and cannot be directly instantiated. If the child contract is also marked `abstract`, the compiler accepts it — but any attempt to deploy an abstract contract (via `new ChildContract()` or direct deployment) will fail at compile time with an error stating the contract is abstract and cannot be deployed. The EVM itself has no concept of abstract contracts; the enforcement is entirely at the Solidity compiler level, preventing malformed deployment bytecode from ever being generated.