1. Multidimensional EIP-1559 For our first project, we create a basic functioning MEIP-1559 simulator with two resources that can later be generalized to higher dimensionality. We build off the work of previous CAMCOS projects by improving transaction modelling and multidimensional resource design. We obtain some qualitative insights using the simulator and some reasoning. 1.1 Preliminaries In the Ethereum Virtual Machine (EVM), a unit of account called gas accounts for the resources used in a transaction. The most modern transaction fee methodology is the August 2021 Ethereum Improvement Proposal 1559 (EIP-1559). This system's main intention was to create a default fee for each block while allowing the block sizes to be able to flucuate appropriately to deal with the network's congestion dynamically.[^16] The design is: When users submit transactions, each transaction has a gas limit and the user supply a max fee which must be at least the basefee (see below). The protocol computes a basefee that updates every block with the function: $$b_c = b_p * (1 + 1/8 * \frac{g_p - g_t}{g_t}).$$ Here, $b_c$ is the current block's basefee (with units of fee per gas), $b_p$ is the parent block's basefee, $g_p$ is the parent block's amount of gas, and $g_t$ is the fixed gas target for each block. [^16] The basefee increases for the block if the amount of gas in the parent block is higher than the fixed gas target, and decreases if the parent block's gas is lower than the gas target. When a miner picks up a transaction into a block, the user pays the entire amount of the max fee (per unit of gas in the gas used, which is upper bounded by the gas limit). Out of this, the basefee is burned (destroyed permanently), and the miner gets all the tips on top of the basefee. As an example, if the user offers a tip of 300 gwei/gas and the basefee is 200 gwei/gas, the miner pockets 100 gwei/gas and the user loses 300 gwei/gas when her transaction is accepted.

new scratchwork file: https://hackmd.io/z41LtNNWRjSHthaBTjVNjA (files have size limits) 6/9 Market research table Purpose: What is the mainly different between the Arbitrum, Optimism, and Zksync? How many roles are involved in the platforms? Which processuers involved the cost and revenue? | | Aggregator | Sequencer(our model) |Challenger| | ------- | -----------------| ---------------- |--------|

My current plan, in order of priority: try to flesh out Aditya + Barnabe's question(s). It seems nice, open ended, potentially fruitful. However, it's a bit underspecced right now for my tastes. as a backup, work on further EIP-1559 stuff, starting with multidimensional EIP-1559. (Aditya + Barnabe) The Ethereum User Experience This is an attempt to summarize and clarify Aditya and Barnabe's ideas, trying to convert them to projects that would make sense for either a current CAMCOS project or next semester's CAMCOS project. From my understanding, the main question here is:

(thanks to Vitalik Buterin for conversation and feedback) Motivation In A model for cumulative committee-based finality - Consensus - Ethereum Research, we see a long-term proposal for single-round finality schemes with the concept of inactivity leaks. This document attempts to map out the concept in detail, so we can start asking concrete questions. I think of the setup as the following: We have some proof-of-stake protocol based on rounds each round, there is a committee (a subset of the validators) who participate in some sort of consensus algorithm CONSENSUS. One of 3 things happen: