Quiz
Last updated
Was this helpful?
Last updated
Was this helpful?
Q1 Which of the following is/are true about abstract contracts and interfaces?
Comment:
Note that A isn't necessarily correct since abstract classes can have all functions defined.
Abstract Contracts: Contracts need to be marked as abstract when at least one of their functions is not implemented. They use the abstract keyword.
Interfaces: They cannot have any functions implemented.
Virtual Functions: Functions without implementation have to be marked virtual outside of interfaces. In interfaces, all functions are automatically considered virtual. Functions with private visibility cannot be virtual.
Q2 Libraries are contracts
Comment:
Libraries: They are deployed only once at a specific address and their code is reused using the DELEGATECALL opcode. This means that if library functions are called, their code is executed in the context of the calling contract. They use the library keyword.
Library Restrictions: In comparison to contracts, libraries are restricted in the following ways: They cannot have state variables, they cannot inherit nor be inherited, they cannot receive Ether.
Library functions can only be called directly (i.e. without the use of DELEGATECALL) if they do not modify the state (i.e. if they are view or pure functions), because libraries are assumed to be stateless
Q3 Storage layout
Q4 For contract A {uint256 i; bool b1; bool b2; address a1;} the number of storage slots used is
Q5 Which of the following is/are generally true about storage layouts?
Q6 EVM memory
Q7 EVM inline assembly has
Comment:
Inline Assembly: Inline assembly is a way to access the Ethereum Virtual Machine at a low level. This bypasses several important safety features and checks of Solidity. You should only use it for tasks that need it, and only if you are confident with using it. The language used for inline assembly in Solidity is called Yul.
Inline Assembly Access to External Variables, Functions and Libraries: You can access Solidity variables and other identifiers by using their name. Local variables of value type are directly usable in inline assembly. Local variables that refer to memory/calldata evaluate to the address of the variable in memory/calldata and not the value itself [...]
Q8 Zero address check is typically recommended because
Q9 ERC20 transferFrom(address sender, address recipient, uint256 amount) (that follows the ERC20 spec strictly)
Q10 OpenZeppelin SafeERC20 is generally considered safer to use than ERC20 because
Q11 OpenZeppelin ERC20Pausable
Q12 OpenZeppelin ERC721
Comment:
Not C, since approval is not susceptible since approval can only given or taken away for a single token, so changing approval doesn't allow stealing more than was already approved.
OpenZeppelin ERC721: Implements the popular ERC721 Non-Fungible Token Standard.
safeTransferFrom(..): Safely transfers tokenId token from from to to, checking first that contract recipients are aware of the ERC721 protocol to prevent tokens from being forever locked. Requirements: 1) from cannot be the zero address [...]
setApprovalForAll(address operator, bool _approved): Approve or remove operator as an operator for the caller. Operators can call transferFrom or safeTransferFrom for any token owned by the caller.
Q13 ERC777 may be considered as an improved version of ERC20 because
Comment:
OpenZeppelin ERC777: Like ERC20, ERC777 is a standard for fungible tokens with improvements such as getting rid of the confusion around decimals, minting and burning with proper events, among others, but its killer feature is receive hooks. [...] A hook is simply a function in a contract that is called when tokens are sent to it, meaning accounts and contracts can react to receiving tokens. This enables a lot of interesting use cases, including atomic purchases using tokens (no need to do approve and transferFrom in two separate transactions), rejecting reception of tokens (by reverting on the hook call), redirecting the received tokens to other addresses, among many others. Furthermore, since contracts are required to implement these hooks in order to receive tokens, no tokens can get stuck in a contract that is unaware of the ERC777 protocol, as has happened countless times when using ERC20s.
Q14 The OpenZeppelin library that provides onlyOwner modifier
Q15 OpenZeppelin’s (role-based) AccessControl library
Q16 If OpenZeppelin’s isContract(address) returns false for an address then
Q17 CREATE2
Q18 OpenZeppelin ECDSA
Comment:
OpenZeppelin ECDSA: provides functions for recovering and managing Ethereum account ECDSA signatures. These are often generated via web3.eth.sign, and are a 65 byte array (of type bytes in Solidity) arranged the following way:
[[v (1)], [r (32)], [s (32)]]. The data signer can be recovered with ECDSA.recover, and its address compared to verify the signature. Most wallets will hash the data to sign and add the prefix'\x19Ethereum Signed Message:\n', so when attempting to recover the signer of an Ethereum signed message hash, you’ll want to use toEthSignedMessageHash.
Externally Owned Accounts (EOA) can sign messages with their associated private keys, but currently contracts cannot.
Q19 OpenZeppelin SafeMath
Q20 OpenZeppelin’s proxy implementations
Q21 Proxied contracts
Q22 Dappsys provides
Comment:
Dappsys DSProxy: implements a proxy deployed as a standalone contract which can then be used by the owner to execute code.
Dappsys DSMath: provides arithmetic functions for the common numerical primitive types of Solidity. You can safely add, subtract, multiply, and divide uint numbers without fear of integer overflow. You can also find the minimum and maximum of two numbers. Additionally, this package provides arithmetic functions for two new higher level numerical concepts called wad (18 decimals) and ray (27 decimals). These are used to represent fixed-point decimal numbers. A wad is a decimal number with 18 digits of precision and a ray is a decimal number with 27 digits of precision.
Dappsys DSAuth: Provides a flexible and updatable auth pattern which is completely separate from application logic.
Q23 WETH is
Comment:
WETH: WETH stands for Wrapped Ether. For protocols that work with ERC-20 tokens but also need to handle Ether, WETH contracts allow converting Ether to its ERC-20 equivalent WETH (called wrapping) and vice-versa (called unwrapping). WETH can be created by sending ether to a WETH smart contract where the Ether is stored and in turn receiving the WETH ERC-20 token at a 1:1 ratio. This WETH can be sent back to the same smart contract to be “unwrapped” i.e. redeemed back for the original Ether at a 1:1 ratio. The most widely used WETH contract is WETH9 which holds more than 7 million Ether for now.
Q24 Name collision error with inheritance happens when the following pairs have the same name within a contract
Q25 Which of the following is/are not allowed?
Q26 Solidity supports
Q27 Which of the following EVM instruction(s) do(es) not touch EVM storage?
Q28 Which of the following is/are true about Solidity compiler 0.8.0?
Comment:
ABI coder v2 is activated by default. You can choose to use the old behaviour using
pragma abicoder v1;. The pragmapragma experimental ABIEncoderV2;is still valid, but it is deprecated and has no effect. If you want to be explicit, please usepragma abicoder v2;instead.
Arithmetic operations revert on underflow and overflow. You can use
uncheckedto use the previous wrapping behaviour.
Failing assertions and other internal checks like division by zero or arithmetic overflow do not use the invalid opcode but instead the revert opcode. More specifically, they will use error data equal to a function call to Panic(uint256) with an error code specific to the circumstances. This will save gas on errors while it still allows static analysis tools to distinguish these situations from a revert on invalid input, like a failing require.
Exponentiation is right associative, i.e., the expression a**b**c is parsed as a**(b**c). Before 0.8.0, it was parsed as (a**b)**c. This is the common way to parse the exponentiation operator.
Q29 OpenZeppelin SafeCast
Comment:
OpenZeppelin SafeCast: Wrappers over Solidity's uintXX/intXX casting operators with added overflow checks. Downcasting from uint256/int256 in Solidity does not revert on overflow. This can easily result in undesired exploitation or bugs, since developers usually assume that overflows raise errors. `SafeCast` restores this intuition by reverting the transaction when such an operation overflows.
Q30 OpenZeppelin’s ReentrancyGuard library mitigates reentrancy risk in a contract
Q31 Assuming all contracts C1, C2 and C3 define explicit constructors in contract C1 is C2, C3 {…} and both C2 and C3 don’t inherit contracts, the number & order of constructor(s) executed is/are
Q32 Which of the following is/are true for a function f that has a modifier m?
from point 103.1 of
from point 103.2 of
from point 108 of
from point 103.3 of
from point 113 of
from point 113.6 of
from point 132 of
from point 133 of
from point 151 of
from point 151.4 of
from point 151.7 of
from point 152 of
See the
from point 166 of
from point 168.1 of
from point 193 of
from point 194 of
from point 195 of
from point 198 of
from Solidity v0.8.0 Breaking Semantic Changes, point 142.2 of
from Solidity v0.8.0 Breaking Semantic Changes, point 142.1 of
from Solidity v0.8.0 Breaking Semantic Changes, point 142.4 of
from Solidity v0.8.0 Breaking Semantic Changes, point 142.3 of
from point 177 of
