Bta Certified Blockchain Developer - Ethereum Free Sample Questions

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.

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.