CBDE Sample Questions & Answers

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.

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.

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.

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.

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.

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.

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.

While Mocha is the testing framework and Ethers.js is the library for interacting with Ethereum, Waffle (now integrated into Hardhat via @nomicfoundation/hardhat-chai-matchers) provides the blockchain-specific assertions. It extends the Chai assertion library with matchers like to.be.revertedWith(), to.emit(), and to.changeEtherBalance(). These are essential for writing expressive and effective smart contract unit tests.

For short, fixed-size strings, using the fixed-size byte array types (bytes1, bytes2, ..., bytes32) is significantly more gas-efficient than the dynamically-sized string or bytes types. Since a 4-character ASCII string fits within 4 bytes, bytes4 is the optimal choice. It allows the data to be packed efficiently into a single 32-byte storage slot, whereas string and bytes have additional overhead for storing the length.

EIP-1559 introduced two key changes: a predictable, algorithmically adjusted base fee that is burned, and an optional priority fee (tip) paid to miners. The burning of the base fee reduces the overall ETH supply, creating deflationary pressure. The programmatic adjustment of the base fee based on block fullness makes gas prices more predictable for users, as they no longer have to guess the market rate in a first-price auction system. It does not fix gas prices, but rather makes their fluctuations smoother and more transparent.