Free CBDE sample questions

Correct answers: Adhere to the Checks-Effects-Interactions pattern.; Use the `transfer()` method instead of `call()` for sending Ether.

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.

Correct answer: False

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.

Correct answer: Writing a series of JavaScript deployment scripts in the `scripts/` directory and executing them with `hardhat run`.

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.

Correct answer: `receive() external payable { ... }`

The `receive()` external payable function is specifically designed to handle plain Ether transfers to a contract where no data (`msg.data`) is sent. It is the most gas-efficient way to receive Ether. A `fallback()` function can also receive Ether, but it's a more general-purpose function that also executes when a call is made to the contract with no matching function signature. If the goal is only to receive Ether, `receive()` is the correct and more specialized choice. A regular `payable` function like `deposit()` would require the sender to explicitly call that function with its signature, which is not the standard way to simply send Ether to a contract.

Correct answer: By creating a read-only contract instance connected to a Provider and calling the `view` or `pure` functions directly.

Functions in Solidity marked as `view` (reads state) or `pure` (does not read or modify state) do not alter the blockchain's state. Therefore, they can be called without sending a transaction and incurring gas costs. A dApp's frontend uses a Provider (like Infura or Alchemy) to connect to an Ethereum node and make these read-only calls. A Signer is only required for transactions that modify state and need to be signed by a user's private key. The EVM executes the function call locally on the connected node and returns the result without broadcasting a transaction to the network.

Correct answer: The array has grown over time, and the gas required to loop through it now exceeds the block gas limit.

The most probable cause is that the function's gas cost has surpassed the block gas limit. Each Ethereum block has a maximum amount of gas that can be consumed by all transactions within it. If a single transaction requires more gas than this limit, it can never be included in a block, regardless of the gas limit set by the user. Loops that iterate over unbounded arrays in storage are a common anti-pattern that leads to this problem, as the gas cost grows linearly with the size of the array.

Correct answer: Using a trusted oracle service that provides a Verifiable Random Function (VRF).

Using on-chain data like `block.timestamp` or `blockhash` is highly insecure, as miners can manipulate these values to their advantage. A Verifiable Random Function (VRF), typically provided by oracle services like Chainlink, is the industry standard for secure on-chain randomness. A VRF generates a random number and a cryptographic proof that the number was generated verifiably randomly. The smart contract can then verify this proof on-chain, ensuring that neither the oracle nor the miners could have tampered with the outcome. The commit-reveal scheme is better than on-chain data but can still be complex and less secure than a dedicated VRF service.

Correct answer: Keep a running `rewardPerToken` value that is updated every time the total staked amount changes. When a user interacts with the contract (stakes, unstakes, or claims), their individual rewards are calculated based on this value and their last interaction point.

This describes a widely-used and highly efficient pattern for reward distribution, often seen in top DeFi protocols. Instead of looping, the contract tracks a cumulative `rewardPerToken` value. Rewards are effectively 'accounted for' every time total deposits change. A user's earned rewards can then be calculated with a simple formula (`userDeposit * (currentRewardPerToken - userLastRewardPerToken)`) when they choose to interact. This avoids unbounded loops, scales to an infinite number of users, and ensures rewards are calculated fairly up to the exact moment of any action. Batching the loop is a temporary fix that doesn't solve the underlying scalability issue. A simple pull system still requires a complex, potentially gas-intensive calculation for each user.

Correct answer: `abi.encodePacked()` performs a non-standard packed encoding which is more gas-efficient and used for creating compact data for hashing, while `abi.encode()` uses standard ABI padding and is used for external calls.

The key distinction is padding. `abi.encode()` follows the standard ABI specification, padding all elementary types to 32 bytes, which is required for external function calls. `abi.encodePacked()` concatenates the arguments without padding, resulting in a smaller, more gas-efficient byte array. This makes it ideal for use cases like hashing data together (e.g., inside `keccak256`), but it should NOT be used for data sent in external calls, as it can lead to hash collisions and ambiguities.

Correct answer: Within the implementation contract that the proxy points to.

In the UUPS pattern (EIP-1822), the upgrade logic is part of the implementation contract, not the proxy contract. The proxy simply delegates all calls to the implementation. This makes the proxy itself cheaper and simpler. A special function, typically `_authorizeUpgrade`, must be included in the implementation to handle the authorization and execution of the upgrade. This contrasts with the Transparent Proxy Pattern, where the upgrade logic resides in the proxy and is managed by a separate ProxyAdmin contract.