✅Quiz

Q1 Which of the following is/are true about abstract contracts and interfaces?

A) Abstract contracts have at least one function undefined
B) Interfaces can have some functions defined
C) Unimplemented functions in abstract contracts need to be declared virtual
D) All functions are implicitly virtual in 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.

from point 103.1 of Solidity 201 - by Secureum

Interfaces: They cannot have any functions implemented.

from point 103.2 of Solidity 201 - by Secureum

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.

from point 108 of Solidity 201 - by Secureum

Q2 Libraries are contracts

A) That cannot have state variables
B) That cannot be inherited
C) That always require a delegatecall
D) That are not meant to receive Ether

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.

from point 103.3 of Solidity 201 - by Secureum

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.

from point 113 of Solidity 201 - by Secureum

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

from point 113.6 of Solidity 201 - by Secureum

Q3 Storage layout

A) Refers to the layout of state variables in storage
B) Is organized in 256-byte slots
C) Is packed for value types that use less than 32 bytes
D) Always starts on a new slot for reference types

Q4 For contract A {uint256 i; bool b1; bool b2; address a1;} the number of storage slots used is

A) 4
B) 3
C) 2
D) 1

Q5 Which of the following is/are generally true about storage layouts?

A) The number of slots used for a contract depends on the ordering of state variable declarations
B) The slots for struct elements are consecutive
C) The slot s for dynamic array contains the length with individual elements stored consecutively in slots starting at keccak256(s)
D) The slot s for mapping is empty with individual values stored consecutively in slots starting at keccak(h(k).s), where k is the first key and h is a hash function that depends on type of k -> Not consecutively

Q6 EVM memory

A) Is linear and byte-addressable
B) Is reserved by Solidity until 0x7f
C) Can be accessed in bytes using MLOAD8/MSTORE8 -> MLOAD8 does not exist, only MLOAD exists
D) Is non-volatile or persistent

Q7 EVM inline assembly has

A) Its own language called Yul
B) Safety checks just like Solidity
C) Access to all variables in the contract and function where present
D) References to variables as their addresses not values

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.

from point 132 of Solidity 201 - by Secureum

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 [...]

from point 133 of Solidity 201 - by Secureum

Q8 Zero address check is typically recommended because

A) The use of zero address for transfers will trigger an EVM exception
B) Ether/tokens sent to zero address will be inaccessible
C) Ether/tokens sent to zero address can be accessed by anyone
D) Address 0 is the Ethereum Masternode account and is forbidden for access

Q9 ERC20 transferFrom(address sender, address recipient, uint256 amount) (that follows the ERC20 spec strictly)

A) Transfers token amount from sender to recipient
B) sender must have given caller (msg.sender) approval for at least amount or more
C) Deducts amount from sender’s allowance
D) Deducts amount from caller’s (msg.sender’s) allowance

Q10 OpenZeppelin SafeERC20 is generally considered safer to use than ERC20 because

A) It adds integer overflow/underflow checks
B) It adds return value/data checks
C) It adds pause/unpause capability
D) It adds race-condition checks

Q11 OpenZeppelin ERC20Pausable

A) Adds ability to pause token transfers
B) Adds ability to pause token minting and burning
C) Provides modifiers whenPaused and whenNotPaused
D) None of the above

Q12 OpenZeppelin ERC721

A) Implements the NFT standard
B) safeTransferFrom(..) checks for zero-addresses
C) approve(..) is susceptible to race-condition just like ERC20
D) setApprovalForAll(address operator, bool _approved) approves/removes operator for all of caller’s tokens

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.

from point 151 of Solidity 201 - by Secureum

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 [...]

from point 151.4 of Solidity 201 - by Secureum

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.

from point 151.7 of Solidity 201 - by Secureum

Q13 ERC777 may be considered as an improved version of ERC20 because

A) Hooks allow reacting to token mint/burn/transfer
B) It can help avoid separate approve and transferFrom transactions
C) It can help prevent tokens getting stuck in contracts
D) It removes reentrancy risk

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.

from point 152 of Solidity 201 - by Secureum

Q14 The OpenZeppelin library that provides onlyOwner modifier

A) Is Ownable
B) Provides role based access control
C) Provides a function to renounce ownership
D) None of the above

Q15 OpenZeppelin’s (role-based) AccessControl library

A) Provides support only for two specific roles: Owner and User
B) Provides support for different roles with different authorization levels
C) Provides support for granting and revoking roles
D) None the above

Q16 If OpenZeppelin’s isContract(address) returns false for an address then

A) Address is guaranteed to not be a contract
B) Codesize at address is 0 at time of invocation
C) Both A & B
D) Neither A nor B

Q17 CREATE2

A) Deploys two contracts proxy and implementation concurrently
B) Deploys contract at an address that can be predetermined
C) Uses a salt and contract creationCode
D) None of the above

Q18 OpenZeppelin ECDSA

A) Implements functions for signature creation & verification
B) Is susceptible to signature malleability
C) Both A & B
D) Neither A nor B

Comment:

See the source code on GitHub

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.

from point 166 of Solidity 201 - by Secureum

Externally Owned Accounts (EOA) can sign messages with their associated private keys, but currently contracts cannot.

from point 168.1 of Solidity 201 - by Secureum

Q19 OpenZeppelin SafeMath

A) Prevents integer overflows/underflows at compile-time
B) Is not required if using Solidity compiler version >= 0.8.0
C) Both A & B
D) Neither A nor B

Q20 OpenZeppelin’s proxy implementations

A) Typically have a proxy contract and an implementation contract
B) Use delegatecall's from proxy to implementation
C) Cannot support upgradeable proxies
D) None of the above

Q21 Proxied contracts

A) Should use constructors in implementation contract to initialize the proxy’s state variables
B) Should use an external/public initialize() function
C) Should have their initialize() function called only once
D) All of the above

Q22 Dappsys provides

A) A proxy implementation
B) A floating-point implementation with wad & ray
C) A flexible authorization implementation
D) All of the above

Comment:

Dappsys DSProxy: implements a proxy deployed as a standalone contract which can then be used by the owner to execute code.

from point 193 of Solidity 201 - by Secureum

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.

from point 194 of Solidity 201 - by Secureum

Dappsys DSAuth: Provides a flexible and updatable auth pattern which is completely separate from application logic.

from point 195 of Solidity 201 - by Secureum

Q23 WETH is

A) An ERC20 pre-compile for Wrapped Ether built into Ethereum protocol
B) Warp Ether for super-fast Ether transfers
C) Wrapped Ether to convert Ether into an ERC721 NFT
D) None of the above

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.

from point 198 of Solidity 201 - by Secureum

Q24 Name collision error with inheritance happens when the following pairs have the same name within a contract

A) Function & modifier
B) Function & event
C) Function & function -> This can be function overloading
D) Event & modifier

Q25 Which of the following is/are not allowed?

A) Function overriding
B) Function overloading
C) Modifier overloading
D) Modifier overriding

Q26 Solidity supports

A) Multiple inheritance
B) Polymorphism
C) Contract overloading
D) Function overloading

Q27 Which of the following EVM instruction(s) do(es) not touch EVM storage?

A) SLOAD
B) MSTORE8
C) SSTORE
D) SWAP

Q28 Which of the following is/are true about Solidity compiler 0.8.0?

A) ABI coder v2 is made the default
B) No opt-out primitives for default checked arithmetic
C) Failing assert returns the gas left instead of consuming all gas
D) Exponentiation is made right associative

Comment:

ABI coder v2 is activated by default. You can choose to use the old behaviour using pragma abicoder v1;. The pragma pragma experimental ABIEncoderV2; is still valid, but it is deprecated and has no effect. If you want to be explicit, please use pragma abicoder v2; instead.

from Solidity v0.8.0 Breaking Semantic Changes, point 142.2 of Solidity 201 - by Secureum

Arithmetic operations revert on underflow and overflow. You can use unchecked to use the previous wrapping behaviour.

from Solidity v0.8.0 Breaking Semantic Changes, point 142.1 of Solidity 201 - by Secureum

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.

from Solidity v0.8.0 Breaking Semantic Changes, point 142.4 of Solidity 201 - by Secureum

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.

from Solidity v0.8.0 Breaking Semantic Changes, point 142.3 of Solidity 201 - by Secureum

Q29 OpenZeppelin SafeCast

A) Prevents underflows while downcasting
B) Prevents overflows while downcasting
C) Prevents underflows while upcasting
D) Prevents overflows while upcasting

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.

from point 177 of Solidity 201 - by Secureum

Q30 OpenZeppelin’s ReentrancyGuard library mitigates reentrancy risk in a contract

A) For all its functions by simply deriving/inheriting from it
B) Only for functions that apply the nonReentrant modifier
C) By enforcing a checks-effects-interactions pattern in its functions
D) None of the above

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

A) One, that of C1
B) Three, in the order C2, C3, C1
C) One, that of C3
D) Three, in the order C1, C2, C3

Q32 Which of the following is/are true for a function f that has a modifier m?

A) Function f cannot have another modifier because every function can have at most one modifier
B) Function f's code is inlined at the point of _ within modifier m
C) Function f reverts if _ is not executed in the modifier m
D) None of the above

PreviousOpenZeppelin - Proxy Upgrade Pattern NextSlot 4: Pitfalls and Best Practices 101

Last updated 1 year ago