CBDE Practice Questions

False. While this method can prevent direct calls from the blacklisted EOA, it cannot prevent indirect interaction. The blacklisted user can simply deploy a new, intermediate smart contract (a 'proxy' or 'wrapper' contract) and use it to call the target contract. From the target contract's perspective, msg.sender will be the address of the intermediate contract, not the blacklisted EOA, thus bypassing the check. More robust access control might involve checking tx.origin, but that has its own security implications (e.g., phishing attacks).

The tx.origin global variable always refers to the original EOA that initiated the entire transaction chain. If a contract uses require(tx.origin == owner) for an authorization check, it can be exploited. An attacker can create a malicious contract (e.g., a fake NFT minting contract) and trick the legitimate owner into calling it. The malicious contract would then call the target contract's critical function. Because the owner initiated the transaction, tx.origin would be the owner's address, and the check would pass, allowing the malicious contract to act on the owner's behalf. For this reason, msg.sender should almost always be used for authorization.

The ERC721 standard specifies a receiver hook mechanism to prevent tokens from being accidentally sent to contracts that don't know how to handle them. When using safeTransferFrom, the sending contract checks if the recipient is a contract. If it is, it calls the onERC721Received function on the recipient contract. The recipient must implement the IERC721Receiver interface and return a specific magic value (bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))) to acknowledge the receipt. If it doesn't, the transfer is reverted.

A Provider is an abstraction for a connection to the Ethereum network. It allows a dApp to make read-only requests (like getting a balance or calling a view function) and send raw transactions via the JSON-RPC protocol to an Ethereum node (e.g., one hosted by Infura, Alchemy, or a local node like Ganache). It does not handle private keys or transaction signing; that is the role of a 'Signer'.

The diagram correctly illustrates the UUPS pattern. The user interacts with the Proxy, which uses delegatecall to run code from an Implementation contract while using the Proxy's own storage (state). The critical feature of UUPS is that the upgradeTo(...) logic resides within the implementation contract itself. An authorized admin calls this function on the implementation (through the proxy), and this function then updates a storage slot in the Proxy to point to the new implementation address (Implementation_V2). The Proxy's state is preserved across upgrades.

Using the immutable keyword is the optimal solution. An immutable variable can be assigned a value only once, either at the point of declaration or within the constructor. This ensures the value is set at deployment time and cannot be altered thereafter. It is also more gas-efficient than a standard state variable because its value is directly embedded into the contract's bytecode. A constant variable must be known at compile time, which might not be suitable if the supply is determined by a constructor parameter. A standard public or private state variable could be accidentally modified by another function if not properly protected.

The correct approach is to implement a snapshot mechanism. When a proposal is created, the current block number is recorded. The ERC20 token contract should be designed to allow querying a user's balance at a past block number. This prevents users from acquiring tokens after a proposal is live to gain voting power for that specific proposal. OpenZeppelin's ERC20Votes extension is a standard implementation of this pattern. Simply checking the current balance at vote time is vulnerable to this exact exploit.

The Checks-Effects-Interactions pattern is a fundamental principle for preventing reentrancy. It dictates that you should perform all internal state checks and updates (Checks, Effects) before making any external calls (Interactions). Using transfer() (or send()) for sending Ether is another key mitigation because it forwards a fixed, small amount of gas (2300), which is not enough for the receiving contract to make a reentrant call back. Using call() with a large gas stipend is what enables reentrancy. Increasing gas price and using low-level calls do not prevent reentrancy.

False. The delegatecall opcode is unique because it executes the code of another contract but preserves the context of the calling contract. This means that msg.sender and msg.value remain those of the original caller of the function that initiated the delegatecall. This behavior is fundamental to implementing proxy patterns for upgradeable smart contracts.

Hardhat's scripting capabilities, located in the scripts/ directory, are designed for this exact purpose. Developers can write JavaScript or TypeScript files that use the Ethers.js or Web3.js plugins to define a precise, repeatable sequence of deployments and contract interactions. These scripts can be run against any configured network (like localhost or sepolia) using the hardhat run --network command, ensuring consistency and automation. The other options are either manual, not designed for deployment, or part of a different framework.