removing extra space in num lists

content/1. Ethereum101/Stack Memory, Storage, and Flow Operations.md

@@ -14,7 +14,7 @@
 |         0x58          |          PC 0 1           | Get the value of the program counter prior to the increment corresponding to this instruction           |     2     |
 |         0x59          |         MSIZE 0 1         | Get the size of active memory in bytes                                                                  |     2     |
 |         0x5a          |          GAS 0 1          | Get the amount of available gas, including the corresponding reduction for the cost of this instruction |     2     |
-|         0x5b          | <nobr>JUMPDEST 0 0</nobr> | Mark a valid destination for jumps. This operation has no effect on machine state during execution.    |     1     |
+|         0x5b          | <nobr>JUMPDEST 0 0</nobr> | Mark a valid destination for jumps. This operation has no effect on machine state during execution.   |     1     |
 
 [^1]:(Mnemonic, Stack items placed, Stack items removed)
 [^2]: The base cost is shown but may vary based on the opcode arguments.

content/3. Solidity 201/Library Restrictions.md

@@ -1,12 +1,12 @@
 # 113 - [Library Restrictions](Library%20Restrictions.md)
 In comparison to contracts, libraries are restricted in the following ways:
 
-1.  They cannot have [state variables](State%20Variables.md)
-2.  They cannot inherit nor be inherited
-3.  They cannot receive Ether
-4.  They cannot be destroyed
-5.  It can only access state variables of the calling contract if they are explicitly supplied (it would have no way to name them, otherwise)
-6.  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
+1. They cannot have [state variables](State%20Variables.md)
+2. They cannot inherit nor be inherited
+3. They cannot receive Ether
+4. They cannot be destroyed
+5. It can only access state variables of the calling contract if they are explicitly supplied (it would have no way to name them, otherwise)
+6. 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
 
 ___
 ## Slide Screenshot

content/3. Solidity 201/Memory Arrays.md

@@ -1,9 +1,9 @@
 # 128 - [Memory Arrays](Memory%20Arrays.md)
 Memory Layout & Arrays: Elements in memory arrays in Solidity always occupy multiples of 32 bytes (this is even true for `byte[]`, but not for `bytes` and `string`). 
 
-1.  Multi-dimensional memory arrays are pointers to memory arrays
+1. Multi-dimensional memory arrays are pointers to memory arrays
 
-2.  The length of a dynamic array is stored at the first slot of the array and followed by the array elements
+2. The length of a dynamic array is stored at the first slot of the array and followed by the array elements
 
 ___
 ## Slide Screenshot

content/3. Solidity 201/OZ Address.md

@@ -1,21 +1,21 @@
 # 159 - [OZ Address](OZ%20Address.md)
 OpenZeppelin Address: Collection of functions related to the address type:
 
-1.  `isContract(address account)` → `bool`: Returns true if account is a contract. It is unsafe to assume that an address for which this function returns false is an externally-owned account (EOA) and not a contract. Among others, isContract will return false for the following types of addresses: 1) an externally-owned account 2) a contract in construction 3) an address where a contract will be created 4) an address where a contract lived, but was destroyed
+1. `isContract(address account)` → `bool`: Returns true if account is a contract. It is unsafe to assume that an address for which this function returns false is an externally-owned account (EOA) and not a contract. Among others, isContract will return false for the following types of addresses: 1) an externally-owned account 2) a contract in construction 3) an address where a contract will be created 4) an address where a contract lived, but was destroyed
 
-2.  `sendValue(address payable recipient, uint256 amount)`: Replacement for Solidity’s transfer: sends amount wei to recipient, forwarding all available gas and reverting on errors. EIP1884 increases the gas cost of certain opcodes, possibly making contracts go over the 2300 gas limit imposed by transfer, making them unable to receive funds via transfer. sendValue removes this limitation.
+2. `sendValue(address payable recipient, uint256 amount)`: Replacement for Solidity’s transfer: sends amount wei to recipient, forwarding all available gas and reverting on errors. EIP1884 increases the gas cost of certain opcodes, possibly making contracts go over the 2300 gas limit imposed by transfer, making them unable to receive funds via transfer. sendValue removes this limitation.
 
-3.  `functionCall(address target, bytes data)` → `bytes`: Performs a Solidity function call using a low level call. A plain `call` is an unsafe replacement for a function call: use this function instead. If target reverts with a revert reason, it is bubbled up by this function (like regular Solidity function calls). Returns the raw returned data. Requirements: target must be a contract. calling target with data must not revert.
+3. `functionCall(address target, bytes data)` → `bytes`: Performs a Solidity function call using a low level call. A plain `call` is an unsafe replacement for a function call: use this function instead. If target reverts with a revert reason, it is bubbled up by this function (like regular Solidity function calls). Returns the raw returned data. Requirements: target must be a contract. calling target with data must not revert.
 
-4.  `functionCallWithValue(address target, bytes data, uint256 value)` → `bytes`: Same as functionCall, but also transferring value wei to target. Requirements: 
+4. `functionCallWithValue(address target, bytes data, uint256 value)` → `bytes`: Same as functionCall, but also transferring value wei to target. Requirements: 
 
 	1. the calling contract must have an ETH balance of at least value. 
 
 	2. the called Solidity function must be payable.
 
-5.  `functionStaticCall(address target, bytes data)` → `bytes`: Same as functionCall, but performing a static call.
+5. `functionStaticCall(address target, bytes data)` → `bytes`: Same as functionCall, but performing a static call.
 
-6.  `functionDelegateCall(address target, bytes data)` → `bytes`: Same as functionCall, but performing a delegate call.
+6. `functionDelegateCall(address target, bytes data)` → `bytes`: Same as functionCall, but performing a delegate call.
 
 The above `functionCall*` functions have variants which pass an `errorMessage` parameter that specifies the fallback revert reason when target reverts.
 

content/3. Solidity 201/OZ BeaconProxy.md

@@ -3,13 +3,13 @@ OpenZeppelin BeaconProxy: implements a proxy that gets the implementation addres
 
 The beacon address is stored in storage slot `uint256(keccak256('eip1967.proxy.beacon')) - 1`, so that it doesn’t conflict with the storage layout of the implementation behind the proxy.
 
-1.  `constructor(address beacon, bytes data)`: Initializes the proxy with beacon. If data is nonempty, it’s used as data in a delegate call to the implementation returned by the beacon. This will typically be an encoded function call, and allows initializing the storage of the proxy like a Solidity constructor. Requirements: beacon must be a contract with the interface IBeacon.
+1. `constructor(address beacon, bytes data)`: Initializes the proxy with beacon. If data is nonempty, it’s used as data in a delegate call to the implementation returned by the beacon. This will typically be an encoded function call, and allows initializing the storage of the proxy like a Solidity constructor. Requirements: beacon must be a contract with the interface IBeacon.
 
-2.  `_beacon()` → `address beacon`: Returns the current beacon address.
+2. `_beacon()` → `address beacon`: Returns the current beacon address.
 
-3.  `_implementation()` → `address`: Returns the current implementation address of the associated beacon.
+3. `_implementation()` → `address`: Returns the current implementation address of the associated beacon.
 
-4.  `_setBeacon(address beacon, bytes data)`: Changes the proxy to use a new beacon. If data is nonempty, it’s used as data in a delegate call to the implementation returned by the beacon. Requirements: 
+4. `_setBeacon(address beacon, bytes data)`: Changes the proxy to use a new beacon. If data is nonempty, it’s used as data in a delegate call to the implementation returned by the beacon. Requirements: 
 
   1. beacon must be a contract 
   2. The implementation returned by beacon must be a contract.

content/3. Solidity 201/OZ Clones.md

@@ -7,13 +7,13 @@ The library includes functions to deploy a proxy using either create (traditiona
 
 It also includes functions to predict the addresses of clones deployed using the deterministic method.
 
-1.  `clone(address implementation)` → `address instance`: Deploys and returns the address of a clone that mimics the behaviour of implementation. This function uses the create opcode, which should never revert.
+1. `clone(address implementation)` → `address instance`: Deploys and returns the address of a clone that mimics the behaviour of implementation. This function uses the create opcode, which should never revert.
 
-2.  `cloneDeterministic(address implementation, bytes32 salt)` → `address instance`: Deploys and returns the address of a clone that mimics the behaviour of implementation. This function uses the create2 opcode and a salt to deterministically deploy the clone. Using the same implementation and salt multiple times will revert, since the clones cannot be deployed twice at the same address.
+2. `cloneDeterministic(address implementation, bytes32 salt)` → `address instance`: Deploys and returns the address of a clone that mimics the behaviour of implementation. This function uses the create2 opcode and a salt to deterministically deploy the clone. Using the same implementation and salt multiple times will revert, since the clones cannot be deployed twice at the same address.
 
-3.  `predictDeterministicAddress(address implementation, bytes32 salt, address deployer)` → address predicted: Computes the address of a clone deployed using Clones.cloneDeterministic.
+3. `predictDeterministicAddress(address implementation, bytes32 salt, address deployer)` → address predicted: Computes the address of a clone deployed using Clones.cloneDeterministic.
 
-4.  `predictDeterministicAddress(address implementation, bytes32 salt)` → `address predicted`: Computes the address of a clone deployed using Clones.cloneDeterministic.
+4. `predictDeterministicAddress(address implementation, bytes32 salt)` → `address predicted`: Computes the address of a clone deployed using Clones.cloneDeterministic.
 ___
 ## Slide Screenshot
 ![191.png](../../images/3.%20Solidity%20201/191.png)

content/3. Solidity 201/OZ Counters.md

@@ -3,11 +3,11 @@ OpenZeppelin Counters: Provides counters that can only be incremented or decreme
 
 This can be used e.g. to track the number of elements in a mapping, issuing ERC721 ids, or counting request ids. Functions are:
 
-1.  `current(struct Counters.Counter counter)` → `uint256`
+1. `current(struct Counters.Counter counter)` → `uint256`
 
-2.  `increment(struct Counters.Counter counter)`
+2. `increment(struct Counters.Counter counter)`
 
-3.  `decrement(struct Counters.Counter counter)`
+3. `decrement(struct Counters.Counter counter)`
 ___
 ## Slide Screenshot
 ![162.png](../../images/3.%20Solidity%20201/162.png)

content/3. Solidity 201/OZ Create2.md

@@ -3,15 +3,15 @@ OpenZeppelin Create2: makes usage of the `CREATE2` EVM opcode easier and safer.
 
 `CREATE2` can be used to compute in advance the address where a smart contract will be deployed, which allows for interesting new mechanisms known as 'counterfactual interactions’. 
 
-1.  `deploy(uint256 amount, bytes32 salt, bytes bytecode)` → `address`: Deploys a contract using `CREATE2`. The address where the contract will be deployed can be known in advance via `computeAddress`. The bytecode for a contract can be obtained from Solidity with `type(contractName).creationCode`. Requirements: 
+1. `deploy(uint256 amount, bytes32 salt, bytes bytecode)` → `address`: Deploys a contract using `CREATE2`. The address where the contract will be deployed can be known in advance via `computeAddress`. The bytecode for a contract can be obtained from Solidity with `type(contractName).creationCode`. Requirements: 
 	1. bytecode must not be empty. 
 	2. salt must have not been used for bytecode already. 
 	3. the factory must have a balance of at least amount. 
 	4. if amount is non-zero, bytecode must have a `payable` constructor.
 
-2.  `computeAddress(bytes32 salt, bytes32 bytecodeHash)` → `address`: Returns the address where a contract will be stored if deployed via deploy. Any change in the `bytecodeHash` or `salt` will result in a new destination address.
+2. `computeAddress(bytes32 salt, bytes32 bytecodeHash)` → `address`: Returns the address where a contract will be stored if deployed via deploy. Any change in the `bytecodeHash` or `salt` will result in a new destination address.
 
-3.  `computeAddress(bytes32 salt, bytes32 bytecodeHash, address deployer)` → `address`: Returns the address where a contract will be stored if deployed via deploy from a contract located at deployer. If the deployer is this contract’s address, it returns the same value as `computeAddress`.
+3. `computeAddress(bytes32 salt, bytes32 bytecodeHash, address deployer)` → `address`: Returns the address where a contract will be stored if deployed via deploy from a contract located at deployer. If the deployer is this contract’s address, it returns the same value as `computeAddress`.
 
 ___
 ## Slide Screenshot

content/3. Solidity 201/OZ EIP-712.md

@@ -1,13 +1,13 @@
 # 169 - [OZ EIP-712](OZ%20EIP-712.md)
 OpenZeppelin EIP712: EIP 712 is a standard for hashing and signing of typed structured data. This contract implements the EIP 712 domain separator (`_domainSeparatorV4`) that is used as part of the encoding scheme, and the final step of the encoding to obtain the message digest that is then signed via ECDSA (`_hashTypedDataV4`). Protocols need to implement the type-specific encoding they need in their contracts using a combination of abi.encode and keccak256.
 
-1.  `constructor(string name, string version)`: Initializes the domain separator and parameter caches. The meaning of name and version is specified in EIP 712: 
-	1.  `name` is the user readable name of the signing domain, i.e. the name of the DApp or the protocol
-	2.  `version`: the current major version of the signing domain.
+1. `constructor(string name, string version)`: Initializes the domain separator and parameter caches. The meaning of name and version is specified in EIP 712: 
+	1. `name` is the user readable name of the signing domain, i.e. the name of the DApp or the protocol
+	2. `version`: the current major version of the signing domain.
 
-2.  `_domainSeparatorV4()` → `bytes32`: Returns the domain separator for the current chain.
+2. `_domainSeparatorV4()` → `bytes32`: Returns the domain separator for the current chain.
 
-    1.  `_hashTypedDataV4(bytes32 structHash)` → `bytes32`: Given an already hashed struct, this function returns the hash of the fully encoded EIP712 message for this domain. This hash can be used together with ECDSA.recover to obtain the signer of a message.
+    1. `_hashTypedDataV4(bytes32 structHash)` → `bytes32`: Given an already hashed struct, this function returns the hash of the fully encoded EIP712 message for this domain. This hash can be used together with ECDSA.recover to obtain the signer of a message.
 
 ___
 ## Slide Screenshot

content/3. Solidity 201/OZ ERC1155.md

@@ -1,13 +1,13 @@
 # 153 - [OZ ERC1155](OZ%20ERC1155.md)
 OpenZeppelin ERC1155: is a novel token standard that aims to take the best from previous standards to create a fungibility-agnostic and gas-efficient token contract.
 
-1.  The distinctive feature of ERC1155 is that it uses a single smart contract to represent multiple tokens at once
+1. The distinctive feature of ERC1155 is that it uses a single smart contract to represent multiple tokens at once
 
-2.  Accounts have a distinct balance for each token id, and non-fungible tokens are implemented by simply minting a single one of them.
+2. Accounts have a distinct balance for each token id, and non-fungible tokens are implemented by simply minting a single one of them.
 
-3.  This approach leads to massive gas savings for projects that require multiple tokens. Instead of deploying a new contract for each token type, a single ERC1155 token contract can hold the entire system state, reducing deployment costs and complexity.
+3. This approach leads to massive gas savings for projects that require multiple tokens. Instead of deploying a new contract for each token type, a single ERC1155 token contract can hold the entire system state, reducing deployment costs and complexity.
 
-4.  Because all state is held in a single contract, it is possible to operate over multiple tokens in a single transaction very efficiently. The standard provides two functions, `balanceOfBatch` and `safeBatchTransferFrom`, that make querying multiple balances and transferring multiple tokens simpler and less gas-intensive.
+4. Because all state is held in a single contract, it is possible to operate over multiple tokens in a single transaction very efficiently. The standard provides two functions, `balanceOfBatch` and `safeBatchTransferFrom`, that make querying multiple balances and transferring multiple tokens simpler and less gas-intensive.
 
 ___
 ## Slide Screenshot

content/3. Solidity 201/OZ ERC1967Proxy.md

@@ -1,11 +1,11 @@
 # 186 - [OZ ERC1967Proxy](OZ%20ERC1967Proxy.md)
 OpenZeppelin ERC1967Proxy: implements an upgradeable proxy. It is upgradeable because calls are delegated to an implementation address that can be changed. This address is stored in storage in the location specified by EIP1967, so that it doesn’t conflict with the storage layout of the implementation behind the proxy. Upgradeability is only provided internally through `_upgradeTo`.
 
-1.  `_constructor(address _logic, bytes _data)`: Initializes the upgradeable proxy with an initial implementation specified by `_logic`. If `_data` is nonempty, it’s used as data in a delegate call to `_logic`. This will typically be an encoded function call, and allows initializing the storage of the proxy like a Solidity constructor.
+1. `_constructor(address _logic, bytes _data)`: Initializes the upgradeable proxy with an initial implementation specified by `_logic`. If `_data` is nonempty, it’s used as data in a delegate call to `_logic`. This will typically be an encoded function call, and allows initializing the storage of the proxy like a Solidity constructor.
 
-2.  `_implementation()` → `address impl`: Returns the current implementation address.
+2. `_implementation()` → `address impl`: Returns the current implementation address.
 
-3.  `_upgradeTo(address newImplementation)`: Upgrades the proxy to a new implementation. Emits an Upgraded event.
+3. `_upgradeTo(address newImplementation)`: Upgrades the proxy to a new implementation. Emits an Upgraded event.
 ___
 ## Slide Screenshot
 ![186.png](../../images/3.%20Solidity%20201/186.png)