---
tags: Homeworks
---

# HW 3: Ethereum

:::info
**Released:** March 13th, 11:59pm EST
**Due:** March 19th, 11:59pm EST
:::

## Problem 1 (12 Points)

In 2015, The ERC-20 token standard was created, "allow[ing] developers to build token applications that are interoperable with other products and services" ([Ethereum docs](https://ethereum.org/en/developers/docs/standards/tokens/erc-20/), 2021).

The main methods of interest in the IERC20 interface are: `totalSupply`, `balanceOf`, `transfer`, `allowance`, `approve`, and `transferFrom`.

While `transfer` and `transferFrom` may sound similar, their purposes are completely different:
* I call `transfer` if I am the owner of the account. This means that my address is sending a message to the ERC20 token, which keeps track of all account balances.
* Someone (or something) calls `transferFrom` if they are not the owner of the account (a smart contract, another person, etc...)
* In order for another person or contract to transfer on my behalf, I must pre-approve that address to do so, using the `approve(spender, amount)` function, where `spender` is the address I'm allowing to transfer on my behalf, and `amount` is the total amount of my tokens that address is allowed to transfer.

Suppose that we have a token `CS1951L` that implements the `IERC20` interface:

contract CS1951L is IERC20 {
    /* Other methods and fields elided */
    mapping(address => uint256) private _balances;
    mapping(address => mapping(address => uint256)) private _allowances;
    
    /**
     *
     * Requirements:
     *
     * - `spender` cannot be the zero address.
     */
    function approve(address spender, uint256 amount) public virtual override returns (bool) {
        address owner = _msgSender();
        _approve(owner, spender, amount);
        return true;
    }
    
     /**
      * Requirements:
      *
      * - `to` cannot be the zero address.
      * - the caller must have a balance of at least `amount`.
      */
    function transfer(address to, uint256 amount) 
    public virtual override returns (bool) {
        address owner = _msgSender();
        _transfer(owner, to, amount);
        return true;
    }
    
    /**
     * Requirements:
     *
     * - `from` and `to` cannot be the zero address.
     * - `from` must have a balance of at least `amount`.
     * - the caller must have allowance for ``from``'s tokens of at least
     * `amount`.
     */
    function transferFrom(
        address from,
        address to,
        uint256 amount
    ) public virtual override returns (bool) {
        address spender = _msgSender();
        _spendAllowance(from, spender, amount);
        _transfer(from, to, amount);
        return true;
    }
}

#### Question 1:
Alice (address: 0xa11ce) wants to send 500 of her `CS1951L` tokens to Bob (address: 0xb0b00). What should she do? `CS195L`'s address is 0x19511, and assume that she has enough funds to do so.
- [ ] Call `transfer(0xb0b00, 500)`
- [ ] Call `approve(0x19511, 500)` and then once CS1951L is approved to transfer on her behalf, Alice should call `transferFrom(0x19511, 0xb0b00, 500)`
- [ ] Call `approve(0x19511, 500)` and then once CS1951L is approved to transfer on her behalf, have CS1951L call `transferFrom(0xa11ce, 0xb0b00, 500)`

#### Question 2:
Alice has approved another smart contract, `CS1951LTAS` (0xc57a5) to send money on her behalf. If `CS1951LTAS` calls `transferFrom(0xa11ce, 0xb0b00, 500)`, who is the `_msgSender()` in `transferFrom`?
- [ ] 0xa11ce
- [ ] 0xb0b00
- [ ] 0xc57a5

Assume we are now inside of `transferFrom`. Who is the `from` in `_transfer`?
- [ ] 0xa11ce
- [ ] 0xb0b00
- [ ] 0xc57a5

#### Question 3:
If Bob calls `approve(0xc57a5, 500)`, can CS1951LTAS successfully call `transferFrom(0xa11ce, 0xb0b00, 500)`?
- [ ] Yes
- [ ] No

## Problem 2 (12 Points)

In summer 2022, Ethereum executed the “[The Merge](https://ethereum.org/en/upgrades/merge/),” a hard fork that transitioned Ethereum’s consensus mechanism from proof of work (POW) to proof of stake (POS) among other changes. Some projections suggested that this reduced Ethereum’s energy consumption by roughly 99.95%.

Make sure your answers to each question are 150+ words. You will lose points if we find your response(s) lazy and/or unthoughtful.

#### Question 1:
While everyone can agree this is a huge win for the environment, what are some downsides to transitioning from POW consensus to POS?

#### Question 2:
Since the Merge's primary focus is transitioning from POW to POS, it won't tackle Ethereum's elephant in the room: scalability. The Ethereum foundation does have ideas on that front, but they're a little bit further down the line. Pick 2 ideas for scaling Ethereum, and why you think they'll be successful or unsuccessful.

#### Question 3:
Back in 2016, Ethereum implemented another hard fork called the "[DAO fork](https://www.gemini.com/cryptopedia/the-dao-hack-makerdao)" that sought to return funds that had been stolen as a result of an insecure DAO contract. This decision split the blockchain into Ethereum and Ethereum Classic. Many argued that this demonstrated Ethereum's lack of decentralization, since the nodes simply agree to hard forks proposed by the developers. Do you think that the frequency of [Ethereum's many hard forks](https://ethereum.org/en/history/) makes it less decentralized? Explain you rationale.

## Problem 3 (9 Points)

Recall from lecture that an [**Ethereum transaction**](https://ethereum.org/en/developers/docs/transactions/#:~:text=An%20Ethereum%20transaction%20refers%20to,and%20Alice's%20must%20be%20credited.) contains the following fields (post-London fork):

:::info
* **recipient** – the receiving address
* **signature** – the identifier of the sender
* **value** – amount of ETH to transfer from sender to recipient (in GWEI, a denomination of ETH)
* **data** – optional field to include arbitrary data
* **gasLimit** – the maximum amount of gas units that can be consumed by the transaction
* **maxPriorityFeePerGas** - the maximum amount of gas to be included as a tip to the miner
* **maxFeePerGas** - the maximum amount of gas willing to be paid for the transaction (inclusive of baseFeePerGas and maxPriorityFeePerGas)
:::
An example transaction:

{
  from: "0xEA674fdDe714fd979de3EdF0F56AA9716B898ec8",
  to: "0xac03bb73b6a9e108530aff4df5077c2b3d481e5a",
  gasLimit: "21000",
  maxFeePerGas: "300",
  maxPriorityFeePerGas: "10",
  nonce: "0",
  value: "10000000000"
}

#### Question 1:

Suppose that Carol wants to send the following transaction to Bob

{
  from: "0xca401ffffffffff79de3EdF0F56AA9716B898ec8",
  to: "0xb0bffffffffffff79de3EdF0F56AA9716B898ec8",
  gasLimit: "21000",
  maxFeePerGas: "400",
  maxPriorityFeePerGas: "30",
  nonce: "0",
  value: "2_000_000_000"
}

Given the base block fee is 250 gwei, how much ETH will Carol be debitted if this transaction succeeds?

#### Question 2:
Still assuming that the base block block fee is 250 gwei, what is the maximum tip that a miner can take by executing Carol's simple transaction (in ETH)?

#### Question 3:
If she receives a refund, how much ETH will Carol be refunded? An answer of 0 means no refund.

<!-- ## Problem 4
Like Bitcoin, Ethereum miners receive a reward for succesfully mining a block. Unlike Bitcoin, Ethereum has a concept of [ommer blocks](https://www.investopedia.com/terms/u/uncle-block-cryptocurrency.asp)--blocks that were successfully mined around the same time as the "official" block appended to the chain--and gives partial rewards for mining such blocks. Which of the following statements are true?
- [ ] Ommer blocks make mining pools unnecessary. Why join a mining pool when there are more rewards available?
- [ ] Having ommer blocks actually decreases the network security. Transactions included in ommer blocks may leak on to the main chain.
- [ ] The higher the ommer rate (the percentage of blocks that are ommer), the higher the burn rate (the base fee burned as introduced in the London upgrade).
- [ ] If Bitcoin employed a protocol similar to ommer blocks, it would likely have a higher ommer rate.
-->
## Problem 4 (10 Points)

Suppose that scanning the Ethereum blockchain, I find the following game:

pragma solidity ^0.8.10;

contract GuessMyFavoriteColor {
    mapping (address => bytes32) guesses;
    mapping (address => bool) hasGuessed;
    mapping (bytes32 => bool) takenGuesses;
    mapping (bytes23 => bool) public validColors;
    
    address owner;
    bytes32 favoritecolor;
    address token;
    uint pot;
    uint bidAmount;
    bool gameOver;
    
    /* other methods (setup, seeing set of validColors, 
     * refunding, etc...) elided 
     */
    
    modifier canGuess(g bytes32) {
        require(!hasGuessed[msg.sender]));
        require(ERC20(token).balanceOf(msg.sender) > bidAmount);
        require(validColors[g] != "");
        require(!gameOver);
        _;
    }
    
    function guess(g bytes32) public canGuess(g) {
        ERC20(token).transferFrom(msg.sender, address(this), bidAmount)
        pot += bidAmount;
        guesses[msg.sender] = g
        takenGuesses[g] = true;
        hasGuessed[msg.sender] = true;
    }
    
    function revealColor(color bytes32) public {
        require(msg.sender = owner);
        require(!gameOver);
        favoriteColor = color;
        gameOver = true;
    }
    
    function getPayout() public {
        require(favoriteColorHash != "")
        require(guesses[msg.sender] == favoriteColor)
        ERC20(token).transfer(msg.sender, pot)
    }
}

#### Which of the following are reasons that I should be wary of this game?
- [ ] Since there is no commit-reveal pattern, my adversaries can cheat to win the pot.
- [ ] I won't know how much to `approve` this contract to transfer on my behalf, since the pot has no upper bounds.
- [ ] Even if I'm restricted to guessing from the set of valid colors, there's no guarantee that the owner of the contract will reveal a valid color.
- [ ] I can't stop other bidders from stealing my guess.
- [ ] The owner can just guess their own color and take all the spoils.

## Problem 5 (12 Points)

Currently, Ethereum uses a Patricia trie to efficiently keep track of state. Recall that Patricia tries are a special form of radix tries, where $r$ = 2.

While Patricia tries are remarkably efficient, the Ethereum foundation is researching ways to switch to a sparse merkle tree to store state. Which of the following are good reasons to make the switch?

- [ ] Sharding Patricia tries is not efficient, since child nodes rely on their parent node for path dependency.
- [ ] Sparse Merkle trees always prove inclusion using fork-join parallelism, whereas Patricia tries prove inclusion sequentially.
- [ ] Precomputing hashes for sparse merkle trees is relatively simple, since many of the leaves are null. It's therefore easier to cache values in the tree.
- [ ] Sparse merkle trees take up much less space than Patricia tries.
- [ ] Given the way Patricia tries are stored, proving non-inclusion is impossible.
- [ ] Sparse merkle trees have faster inclusion and non-inclusion proofs.