Questions and answers for Secureum's Slot 1: Ethereum 101

# Questions and answers for Secureum's Slot 1: Ethereum 101 ## Document history 2021/10/24 Initial version 2021/10/25 Added some questions misplaced in #questions channel ## Introduction This is meant as a compilation of the questions and answers asked in the channel #slot1-ethereum-101 of Secureum's [official Discord server](https://discord.gg/ym8BtcWUY2) ## Document structure My idea is not to replicate the chats, but to extract the important part of the conversations. This means that sometimes I'll be editing, cutting, rephrasing or otherwise modifying the conversations in order to focus on (what I think is) the essence of the question/answer. Of course, authors will be preserved and credited, and the full chats are available at the linked Discord server. Questions are in no particular order. I'll also try to answer them myself, add comments or point to relevant material. I'm not an expert so my knowledge is limited, and I'll not even try to answer anything I'm not sure about. So, without further ado, let's dive into the content. ## Questions and answers --- **broccolirob:** I had a question about the phrase "uniquely determines a single Ethereum address". I thought a single private key could generate multiple public keys or addresses. Like in Metamask when you click "Create Account" I thought it was using the same private key. Is there a subtle distinction here between Ethereum addresses and an Ethereum account that I'm missing? **Francis_ldn:** [This](https://aitwb-dev.qa-archive-it.org/16516/20210622012604/https://forum.ethereum.org/discussion/11584/can-i-have-a-single-private-key-for-multiple-public-address-wth-different-passphrase-is-it-possible) might help with your question. > [color=#990000] This question is about the difference between a non-deterministic EOA with a public/private key pair, and a hierarchical deterministic wallet based on BIP-32/BIP-44. > Besides Francis_ldn's link, [Mastering Ethereum's chapter 5](https://github.com/ethereumbook/ethereumbook/blob/develop/05wallets.asciidoc) explains it in more detail. --- **parseb:** Did EIP-1559 change in any way the range of considerations at play when auditing a smart contract? **Josselin Feist - Trail of Bits:** One change is that miners can't have free transactions anymore (as basefee is burned). As a result, it decreases the exploitation likelihood of vulnerabilities like a spam attack, where a malicious actor sends a lot of transactions to your contracts. Pre-1559 miners could include transactions without paying gas, while now they will have to pay the basefee. EIP 1559 does not prevent the attacks, but it changes the economic incentives. The transactions were not really free for miners pre-1559, as adding its own transactions means it will remove transactions that would have sent some earning to the miner. So adding its own transactions means reducting its mining profits if the block is full > [color=#990000] [Relevant EIP-1559 document](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1559.md) --- **parseb:** What would an example contract that was rendered more vulnerable as a direct consequence of EIP-1559 look like? To what extent can one think proactively about this? How misguided would I be in assuming that no attack vector was made possible by EIP-1559? **Josselin Feist - Trail of Bits:** I am not aware/can't think of a contract that was rendered more vulnerable as a direct consequence of EIP-1559 (my example was actually the opposite - EIP-1559 slightly decreases the likelihood of some issues). Offchain components might have issues if they mishandle the new formulas etc. The EIP has also [a section on some potential risks (and mitigations)](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1559.md#security-considerations): --- **datapunk:** within a block since miners determine the order of transactions, is it possible to for an empty account to send ether before receiving it? If so, what are the implications? **Josselin Feist - Trail of Bits:** An account cannot send ether that he does not currently have. While the miner can order the transactions, the transactions are executed sequentially, and their impacts are also sequential. For example, if you have a block with: - Tx1: account A sends 10 ethers to account B - Tx2: account B sends 10 ethers to account C If before the block, account A has 10 ethers, and account B and C have 0 ether, then you have two outcomes, based on the ordering. If the ordering is Tx1 then Tx2, at the end, account A and B have 0 ether and account C has 10 ether. If the ordering is Tx2 then Tx1, then Tx2 fails (insufficient funds), but Tx2 is still present in the block. Then Tx1 is executed. As a result, A ends with 0 ether, B with 10, C with 0. **datapunk:** Is it possible that A->B did happen in time before B->C, however, in a block they are ordered in reverse order? Maybe B cannot even send to C before A->B has been included in a previous block? **Josselin Feist - Trail of Bits:** Both transactions are independent. It is the miner that will decide if they are included within the same block, and the order. Put in other words, Tx2 (so B sending to C) can be added in the block before Tx1, and so executed before. However, because in this situation B does not have enough to send to C, the transaction reverts - but the reverted transaction is still included in the block. So you have either: - Block = [ Tx1 (success), Tx2 (success)] - Block = [ Tx2 (reverted), Tx1 (success)] > [color=#990000] The key points here: > - Miners determine which transactions are in a block and the execution order > - The order of the transactions is effectively the order in which the miner executed them > - Even if a transaction fails, it gets included in the block --- **Graeme:** If an EOA's public key is derived from the private key and the account is taken from the hash of public key's last 20 bytes, How is the contract account's account derived? It has no private key. **GDee:** [This](https://docs.openzeppelin.com/cli/2.7/deploying-with-create2) explains it very well but in a nutshell when the contract is created, the address is determined via some algorithm > [color=#990000] The key points here: > - Contract deployment address are determined by the opcode used to deploy. > - For CREATE, the address is `hash(sender, nonce)`, and it has the drawback that it's dependant of the sender's nonce. > - For CREATE2, the address is `hash(0xFF, sender, salt, bytecode)`. This makes the deployment address independent of future events: the contract can be deployed to the precomputed address without a dependence on the sender's nonce. --- **minter:** The EVM isn't involved in EOA to EOA value transfers, so how is the Ethereum state updated for EOA to EOA value transfers? Is it done by miners/nodes who validate and include the transaction? **pragmatics:** ETH is different from all other tokens in that balances are stored in the global state rather then as part of a token's contract storage. The inclusion of a transfer transaction in a block is enough, [no additional "processing" or state update is required](https://docs.ethhub.io/guides/deciphering-a-transaction-on-etherscan/#externally-owned-accounts-eoa-vs-contract-accounts) [Debug logs](https://ethereum.stackexchange.com/questions/2981/what-s-the-role-of-the-evm-in-a-plain-ether-transfer-between-externally-owned-ac) demonstrating an EOA->EOA transfer. --- **abstract:** If the full node loses the state trie, we are able to recover the blockchain but unable to recover the state trie. What would happen? Would this make the ethereum chain unusable? since the key value store is lost. **Throttle:** As long as there is 1 good node, every other node can replicate **broccolirob:** Also, the client/node can always re-sync. It would start at the genesis block 0 and replay every transaction block by block, rebuilding the state database back as it goes. --- **nolanjannotta1:** [Here](https://github.com/ethereumbook/ethereumbook/blob/develop/13evm.asciidoc) it says: "Note that because a smart contract can itself effectively initiate transactions, code execution is a recursive process". Smart contracts cant initiate transactions right? Are they only saying that smart contracts can call other smart contracts, but the transaction has to originate from an EOA? **0xTaylor:** Yes, they are referring to contracts being able to make external calls. --- **TimmyToes:** It would be mathematically possible (although very unlikely) to have a private key that generates the public address of a contract. If this situation did occur, what would the EVM do if it received a properly signed transaction to transfer ETH from a contract address, signed by such a private key, as though the contract address were an EOA? **broccolirob:** According to the Yellow Paper, even if you had the private key corresponding to that account (effectively making an EOA from a Contract Account), you would not be able to send a valid transaction transferring the account's ether balance to another account. See Page 8, 6. Transaction Execution, initial tests of intrinsic validity #4. Apparently the exact thing we're talking about was added to the yellow paper just 3 days ago (git history)! It says there is currently an [open EIP](https://eips.ethereum.org/EIPS/eip-3607) on this issue. That means it IS, in fact, currently possible to send a transaction transferring the ether balance to another account. I guess they are in the process of fixing it, though. --- **bcavg:** What happens if some bug/flaw has been found in a smart contract? Since its immutable, what happens if it has millions locked in? How is this scenario handled in web3? **broccolirob:** A lot of projects use proxy contracts, so the storage lives on the contract account of the proxy, and all calls to functions (that manipulate that storage) get forwarded via delegatecall to an implementation contract. The proxy can be updated to point to a different implementation contract address, so business logic can be changed (while maintaining storage state) if they discover a critical bug or want to add a new feature. For projects that don’t use proxies, what I’ve seen usually happen is a white-hat hacker (in consultation with the project’s team) will trigger the exploit and take all the “at-risk” funds before a black-hat hacker can. Then they deploy a new contract that fixes the bug, and the white-hat + team will re-deposit the funds and ask users to migrate. There might be other ways of handling things like this, but these are the two that I know of. --- **Tom:** How is the difficulty adjusted on Ethereum when hash rate goes up or down? **Tom:** Replying to myself [in case anyone else is wondering](https://eips.ethereum.org/EIPS/eip-100). --- **Xinshu:** The in-place code update with CREATE2 looks curious. I'm wondering whether that means the creator of a smart contract can literally destroy a smart contract and wipe out the states? Yes, people might have backups of old states but they are no longer part of the blockchain and thus can be disputed. **Rajeev | Secureum:** Yes, CREATE2 brings in certain considerations when used along with SELFDESTRUCT. I had tried to summarize some discussions on this around the time CREATE2 was introduced — see [here](https://ethereum-magicians.org/t/potential-security-implications-of-create2-eip-1014/2614) --- **ych18:** I want to know if a transaction is sent, it will be validated first by the miners and then executed in the evm or executed first and then validated? *(validated in this context meant "put the transaction in a block in the chain")* **tqts:** The miners form a block by choosing transactions from the mempool, and executing them. Then, they mine the block by bruteforcing the nonce to meet the difficulty condition. See point 4 [here](https://ethereum.org/en/developers/docs/consensus-mechanisms/pow/mining/) --- **TimmyToes:** `Memory arrays with dynamic length can be created using the new operator` If the length of the array cannot be resized, in what way is it dynamic length? **GDee:** Dynamic in the sense of the length is defined at runtime and not compile time ## Resources shared ### Developed by bootcamp participants - [0xTaylor's Secureum mind map](https://github.com/x676f64/secureum-mind_map) - [patrickd's Secureum Bootcamp Ethereum 101 Quiz](https://ventral.digital/posts/2021/10/17/secureum-bootcamp-ethereum-101-quiz) ### Other resources - [Ethereum virtual machine opcodes](https://ethervm.io/) - [Ethereum Beige Paper](https://github.com/ethereumbook/beigepaper) - [The Crypto-conundrum Devs corner](https://thecryptoconundrum.net/ethereum_explained/developers_corner.html) - [Computerphile: Endianness](https://www.youtube.com/watch?v=NcaiHcBvDR4) - [Computerphile: Elliptic curves](https://www.youtube.com/watch?v=NF1pwjL9-DE) - [How does Ethereum work, anyway?](https://www.preethikasireddy.com/post/how-does-ethereum-work-anyway) - [Merkling in Ethereum](https://blog.ethereum.org/2015/11/15/merkling-in-ethereum/) ## Closing notes If you feel I should add something, or there's a mistake in the contents, feel free to contact me (`@tqts#0820`) at Secureum's Discord server.