Smart Contract Development Flashcards
6 cards from real Blockchain Technology practice questions. Tap to flip, then mark Knew It or Still Learning — missed cards come back until you master them.
Read the first 6 Smart Contract Development flashcards as text
A development team is building a decentralized finance (DeFi) application where security and auditability are the highest priorities. The contract's logic is straightforward, but it will handle significant financial value. Which smart contract language would be the most suitable choice based on its design philosophy?
Answer: Vyper, because it is designed for simplicity, security, and auditability by intentionally limiting complex features.
Vyper is designed with a focus on security, simplicity, and auditability. It intentionally omits complex features like inheritance and function overloading to reduce the attack surface and make the code easier to review, which is ideal for high-value, straightforward financial applications. Solidity is more feature-rich but its complexity can introduce vulnerabilities. Yul is a low-level language for optimization, not primary development. JavaScript is not a native smart contract language for the EVM.
During a security audit of a smart contract, you discover a function that sends Ether to an external address before updating the contract's internal state that records the sent amount. Which common vulnerability does this pattern introduce?
Answer: Reentrancy
This pattern is a classic example of a reentrancy vulnerability. A malicious external contract can call back into the original function (re-enter) before the state is updated, allowing it to drain funds. The recommended mitigation is the Checks-Effects-Interactions pattern, where all internal state changes (Effects) are made before calling external contracts (Interactions).
A developer is writing a smart contract function in Solidity that should only read from the blockchain's state but not modify it. Which function visibility keyword is most appropriate and gas-efficient for this purpose when called externally?
Answer: view
The `view` keyword is used for functions that read contract state but do not modify it. When called externally (e.g., from a user's wallet), `view` functions do not consume any gas because they do not create a transaction on the blockchain. `pure` functions neither read nor modify state. `public` and `internal` do not, by themselves, specify whether the state is modified, and a regular `public` function would consume gas if it were to modify state.
Which of the following is a critical step that should be performed *before* deploying a smart contract to the mainnet to ensure its security and correctness?
Answer: Engaging a reputable third-party firm for a comprehensive security audit.
Due to the immutable nature of smart contracts, it's crucial to identify and fix vulnerabilities before deployment. A third-party security audit provides an expert, unbiased review of the code to find potential flaws that the development team might have missed. While other steps are part of a project launch, the security audit is a non-negotiable step in the development lifecycle to protect user funds and the project's reputation.
A developer needs a local blockchain environment for rapid development, testing, and debugging of Ethereum smart contracts. This environment should offer features like stack traces for Solidity, mainnet forking, and a rich plugin ecosystem. Which development framework best fits these requirements?
Answer: Hardhat
Hardhat is a professional development environment for Ethereum that provides a flexible and extensible framework for testing, deploying, and debugging smart contracts. Its key features include the Hardhat Network (a local Ethereum network), detailed stack traces for Solidity, mainnet forking capabilities, and a vast ecosystem of plugins, making it ideal for complex development workflows. Remix is a browser-based IDE, Ganache is a local blockchain GUI, and OpenZeppelin provides secure contract libraries, but Hardhat is the comprehensive development environment that meets all the specified criteria.
To prevent integer overflow and underflow vulnerabilities in Solidity versions prior to 0.8.0, what was the standard best practice?
Answer: Utilizing the SafeMath library.
Before Solidity 0.8.0, which introduced built-in overflow and underflow checks, the standard and most secure practice was to use a library like OpenZeppelin's SafeMath. This library provides functions (e.g., `add`, `sub`, `mul`) that check for overflow/underflow conditions and revert the transaction if they occur, preventing this critical vulnerability.