Blockchain Quiz

immutable variables are assigned once (typically in the constructor) and then become read-only. They are stored in bytecode rather than regular storage slots, which can reduce gas compared to storage reads. This matters in Solidity interviews because immutables are common in optimized contracts (e.g., router addresses) and in secure configuration patterns.

Minimal proxy clones (EIP-1167) keep logic in an implementation and rely on proxy bytecode forwarding calls, making deployment cheap. In practice, immutables in the implementation help keep runtime reads efficient and reduce repeated storage reads for configuration-like values. Candidates are often tested on why clones save gas and how configuration is safely handled.

The Checks-Effects-Interactions (CEI) pattern reduces reentrancy by making you validate inputs and update internal state before any external call (like ETH transfer or token transfer). If a malicious contract re-enters, state has already moved forward, limiting exploitability. Many interviewers treat CEI as a must-know Solidity security habit for production contracts

Low-level CALL (and friends like DELEGATECALL) returns a success flag rather than automatically bubbling a revert. If you don’t check that boolean (or decode return data properly), your contract may continue in a “success-looking” state while the external call actually failed. This is a classic Solidity audit finding tied to unsafe external interactions.

A happy-path-only focus is a strong signal of poor threat modeling in blockchain security because it ignores attacker behavior, edge cases, and abuse scenarios. Strong smart contract audit readiness requires adversarial thinking, not just normal-flow testing.

Front-running is often downgraded incorrectly in smart contract audits because teams underestimate MEV and mempool-based exploitability. In DeFi security, transaction ordering attacks can cause repeated economic loss even without a classic code exploit.

Access control bugs often have the highest real-world exploit probability in smart contracts because attackers can directly call privileged functions when role checks fail. In blockchain security audits, broken authorization logic is a common cause of fund loss and protocol takeover.

CALLCODE is deprecated due to unsafe context handling. It remains callable for backward compatibility but should never be used in new designs.

EXTCODESIZE returns zero for EOAs and non-zero for deployed contracts. This distinction is commonly used for contract detection, though it has edge cases.

GASLEFT returns the amount of gas remaining in the current execution context. It is commonly used for gas-aware logic and debugging.

bytes32 always occupies a full 32-byte storage slot. Smaller types may be packed together, but bytes32 always stands alone.

Solidity packs struct variables tightly into storage slots based on declaration order. Reordering fields can change slot boundaries and break upgrade compatibility.

The base slot of a mapping is derived using keccak256(key . slot). This hashing ensures unique storage locations per key without collisions.

Changing variable types alters how Solidity packs them into storage slots. This can shift offsets and corrupt existing storage layouts in upgradeable contracts.

Calldata is immutable and cannot be modified by the callee. This makes it gas-efficient and safe for external function inputs

Storage is not automatically wiped when a contract self-destructs. The data remains on-chain and can be accessed again if a contract is redeployed at the same address.

bytes32 has a fixed 32-byte size and fits into a single storage slot. string is dynamically sized and requires additional storage pointers and length metadata.

Using delete on a dynamic array sets its length to zero. Storage slots may remain allocated but become inaccessible through the array.

Deleting a mapping key resets its value to the default type value. The key itself still exists conceptually since mappings do not track keys.

Storage persists on-chain across transactions and blocks. Memory and calldata are temporary and cleared after execution completes.