# CAMCOS Spring 2022 Project - Scratchwork

- 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|
| ------- | -----------------| ---------------- |--------|
| Responsibility |Wrap the tx and sent them to the on-chain smart contract|Collecting and compressing the tx then send the main chian|Verifying the tx and compute state pubilished by the aggregators.|
|How to become|Anyone send a deposit to the on-chain smart contract|Anyone send a deposit to the on-chain smart contract|Anyone who post their own bond and challenge the assertion|
|Compensation|Pay by users, include in the transaction|Pay by users, include in the trasaction|The deposit of the aggregator|
|Punishment|Deposit will be slashed|Apart of compensation will be slashed| Lose their bond

#### (6/5) Table

Recall that when an L2 design chooses a paradigm of proof (fraud or validity), this forces a specific L1 smart contract design. We are looking at services for which an operator can be held accountable within a design.

The following tables considers different additions to the rules of an L2 that would add explicit support for more complex behavior on an L2. For the first table, we show extensions of the main idea of "including a transaction into a block," starting with our most basic service of simple transaction inclusion:

|Service|Implementation|requirements/potential overheads|target audience/existing implementation|
|---|---|---|---|
|Simple Inclusion|User sends a single transaction to be included.|none |everyone|
|Sequenced|User sends a sequence of transactions, and the transactions must be included in order (although skipping transactions is okay) |Sequencer now needs to verify order and store tx if not done at once|If L3 is going to be supported or other recurrsive rollups sequence guarantees would ease implementation|
|Atomic| User sends a sequence of transactions. All the transactions must be included in the same batch, if any are to be included. User must label the pieces of the transactions (Potentially sequencer within distributed context) |The sequencer can package the tx with overhead of verifying all the flagged tx are together. (easiest is require all tx be flagged that are grouped, MEV allowing is more costly as groupings are less distinct). Alternatively can add more overhead in some implementations as the sequencer must first verify all the tx will go through in the proposed state of the block or be open to slashing. |users with knowledge but low funds, MEV finders,zkopru and hermez **[x]** |
|Grouped|atomic but also sequential|can be a modest overhead based on number of tx, sequencer can to some extent just treat them like one large tx with 1 gas value and 1 price. most of the cost would be opportunity|MEV, apps trying to sequence calls, maybe easier verification for users if paying back a group|

|Service|Implementation|requirements/potential overheads|target audience/existing implementation|
|---|---|---|---|
|Anonymization|Varying degrees, simplist is only recording tx record not details on L1|implementation dependent some degree given by zk, also methods that don’t store data on L1| high value tx, tx with possibility of being front run, non simple tx **[x]**|
|L2 confirmation|Generates a message on/off chain to an address when the sequencer does an attempt at including the tx in a batch|message after L1 posting returned to users|urgent tx that may be canceled, cautious users[**x**] currently indirrect via sequencer feed|
|L2 confirmed to user|Sequencer generates a token that is sent to the user with signed a batch #. If the tx is not recorded in L2 and appearing on L1 the user can submit the token on L1 and recieve a slashing reward | <!-- message w/token after sequencer decides to include that proscribes a L2 batch # so a user that is not included after that point can slash the sequencer. --> Generating the token and returning it are overhead to the sequencer and requires user monitoring. | any user wanting tracking, commerce, high value tx that want to be sure things occur|
|Escape hatch|L1 smart contracts running L2 support user generated proof of some L2 ownership that allows L2=>L1 fund transfer|requires some increased complexity for zk rollups, more so for optimistic, increases cost of setting up initial L2 smart contracts on L1 but need not increase tx overhead|safety concious users, users interested in riskier/newer L2s, used by many zk rollups and some optimistic, if L1 is truly agnostic this is a strong guarantee **[x]**|
|Recurring tx|The sequencer accepts a set of transaction where the transaction is repeated is succesive blocks as user selects|adds off chain storage cost to sequencer depending on size and time constraints, can be verified after the fact that something is in sequential batches. Risky the longer time period is offered if strict guarantee. Increased tx size so that inclusion of all batched tx is verifiable. similar would be delayed or slow below|Support of anonymizing protocols, running smart contracts, proof of livliness |
|Slow tx/lower cost|Somewhat a default behavior, this allows explicit binning for user and sequencer.|Adds offchain storage cost to sequencer but may allow them to profit off the priority fee difference over the time period. User is trading paying the storage cost for letting the sequencer place it freely but in a bounded batch#.(so distinct in that the user is getting a guarantee it will be by some batch number.) So the sequencer is also required to do some predictive work|non urgent users, cost concious users, large numbers of unordered simple tx.|
|Delayed tx|User defines a time or batch number after which they want the next batch to include their tx. Longer times require price increases or better prediction|Adds offchain storage cost, risk of L1 priority fee increases, cost of generating a token for the user(for strong guarantee). opportunity cost of inclusion at the later block for other tx.[alternatively just allow users to specify batch # for tx w/o guarantee of inclusion]|more complicated trading/MEV, L2 apps(games or automated payments like billpay)|Storage|
|Order tx|User can specify tx that are |Adds need for additional market or prefrence ordering|MEV, more complicated L2 apps **[x]** |

Some remarks:
- Anything involving guarantees of more than 1 tx has the overhead of increasing the tx size for verifiability. In most cases this probably only needs to be about a byte.

Most of these transaction types can be implemented orthogonally but share overhead. There are also some hierarchical structure, for example:
- Atomic tx can be a strict prequistite for grouped or batched tx.
- Batched also depends on Delayed.
- Sequenced transactions are a subset of grouped and delayed.

Here is a compact version of the types of overhead associated with each transaction:

| Storage | Computation | Communication |Implementation|
| -------- | -------- | -------- |--------|
| L2 information; Sequenced and order; Delayed;low value; recurring; | Anonymization; L2 confirmation; atomic tx; grouped tx; sequenced tx |ordered tx; L2 confirmation | all |

The costs with adding most additional transactions type will include some onetime implementation cost. Some computational storage or communication overhead. Furthermore the L2 will become less efficient as the abillity to compress transaction dataa decreases the more unique calls that are made in a batch. Therefore L2's may be better off selecting transaction types that support only the feature set they are trying to promote. An example of this is existing L2's that only support simple transactions tend to have higher compression ratios. One question is how much of the advantages in compression for ZKP systems is the reduced scope and corrosponding compression advatanges; vs the validty proof structural advantage.

The services offered would impact the price model primarily in $G(X)$ where the interactions with other transaction types would be reflected and the additional computation would be captured. Some of the transaction type services can offer reduced prices from interacting with $C$ as having well structured data increases the compression ratio.

note on grouped tx
In the grouped tx case there is the posibility that this might not increase cost to the user. Since part of the work a sequencer is doing is packing a batch having a large tx block at some reasonable price maybe prefered to additional small tx. When solving a knapsack having fewer objects usually reduces the amount of steps required. So if some one is paying the "mean price" they may not need to pay more for all of their tx to be guaranteed proximal as it eases the sequencers job. This is a similar idea to buying in bulk in other formats and here is also due to increased compression guaranteed to sequencers.

#### (6/1) lazy eval stash

### 3.4 alt Lazy eval motivation
One concern a user might have regarding pricing is that the price they are being charged for L1 inclusion is not being accurately assesed to them. As seen in section 2 users can encounter a variety of ways of paying for their portion of the cost of including the batch to L1. Lazy evaluation is providing a one step method of offering a **zero slippage** price for the L1 cost. Zero slippage meaning the user is paying exactly the L1 inclusion cost.

### new explanation
Potential issues: L2 Operators and L1 miners are distinct so potential to overpay via the miner not the sequencer. This can be remidied by making it a slashable offence to overpay by some metric.

### Lazy evaluation of pricing
Lazy evaluation for pricing is desirable as a mechanism for creating a zero slippage pricing mechanism for the L1 cost of inclusion to L2 users. Users who want to be assured that the price they are paying is linked to L1 prices may care about this.
Goal of this subsection is to provide Fermi calculation of the overhead created by lazy evaluation.

Currently following suggests that in some cases lazy evaluation is a relatively low overhead cost but that as scaling get better the incentive for zero slippage goes down.
The conclusion is vague because of uncertainty as to how storage on chain is conducted.

There are two implementations for lazy evaluation.
One is assuming we want full data availability with no extra work about account changes to be recorded on L1. (this case for data available L2’s)

**When a current account state is recorded after a batch with the following assumptions:**
1a naive interpretation of the op codes
2 an implementation of lazy evaluation that requires a fixed value for each account at the conclusion of each batch.

Fermi estimate of cost efficiency

This is motivated as data availability is why zk and optimistic rollups are used so if we leave the L1 call data as a reference it adds work to following L2 state.
Depending on structure 10-1000 gas per tx edit. Generously lets say 10(~3 ops).
Currently data available L2 offer scaling of 10-300x
21000 gas simple tx so roughly 2100 gas to 70 cost per tx scaled.
So overhead is at least 0.5% very optimistically. (Arbitrum max scaling of 270x and only 10 gas per tx)
At Dr Zhang’s guess of 100 gas
At worst its over 2x the cost for Arbitrum.
Maybe reasonable/atractive to users for optimism at 5% of the cost of a tx

One thing I struggled to figure out is if to do editing tx pricing would need to load call data to operate on or if it would be there already from writing initially.
This would dramatically increase the cost

For this type as scaling gets better the cost of 0 slippage becomes dispraportionate.

**If references are allowed to be passed**
Then there is only a flat fee per batch
Can compromise immediate data availability but allows for flat scaling on batches(does lose optionality must be for all tx)
Initially looks promising for off chain storage L2’s.
But their efficiency comes from compression/hashing from L2 to L1 since they are passing to L1 proof of a recorded L2 state rather than data about that state may not have interoperability that allows post-hoc modification of tx fees.
Still maybe an option to record and update L2 state after publication to L1,
this probably works better with PoS as there is not a concern about uncle blocks and finalization exists.

#(5/30) Ajust research market to match the current version
#### 2.5.3 Current Revenue model (for Optimitic Rollup)

#### Arbitrum

fee= L2 fee + L1 fee
$G_A *b_A= L2\; fee$: a base fee for each L2 transaction, to cover the cost of servicing a transaction. The base price $(b_A)$ of an L2 transaction is set by each aggregator, using an Arbitrum precompile, subject to a system-wide maximum.

$b_A \ge \frac{b_{estimated}}{100}$: The minimum ArbGas price is set equal to the estimated L1 gas price divided by 100. The price of ArbGas will never go lower than this.

$G_1 * b_{estimated}$ is L1 calldata: a fee per units of L1 calldata directly attributable to the transaction (as on Ethereum, each non-zero byte of calldata is 16 units, and each zero byte of calldata is 4 units).The base price of a unit of L1 calldata is just the estimated L1 gas price

ArbGas: the cost of a computation on Arbitrum.

Users can choose to submit their transactions through an aggregator or not. Besides the L2 tx and L1 calldata fee, users in Arbitrum also need to pay computation fee: a fee per unit of ArbGas used by the transaction and
storage fee: a fee per location of EVM contract storage, based change in EVM storage usage due to the transaction.
#### Optimism

fee= L2 fee + L1 fee

$0.001*G_U$ is L2 execution fee= tx.gasPrice * l2GasUsed
where tx.gasPrice is usually 0.001 gwei, but might change depend on the congestion Optimism dashboard [^10]. l2GasUsed = the amount of computation and storage that they use.

$1.24b_c(G_U+2100)$ is L1_data_fee = L1_gas_price * (tx_data_gas + fixed_overhead) * dynamic_overhead

The L1 data fee based on four factors:

1. L1_gas_price = the current gas price on Ethereum (at most the user will pay no more than 25% expected) [^8]
2. tx_data_gas = the gas cost to publish the transaction to Ethereum. This scales roughly with the size of the transaction (in bytes).
(tx_data_gas = count_zero_bytes(tx_data) * 4 + count_non_zero_bytes(tx_data) * 16)
4. fixed_overhead: Cost denominated in gas. The cost of adding a transaction to a batch decreases as the total batch size increases.This is currently set to 2100 [^8].
5. A dynamic overhead cost which scales the L1 fee paid by a fixed number. This is currently set to 1.24 (This value covers the change in L1 gas price between the time the transaction is submitted and when it is published, as well as the income we need to keep our system running).

The previous fixed overhead and dynamic overhead were 2750 and 1.5 which means Optimism was able to reduce the cost up to 30% [^8]

Users are not able to set limits for the L1 data fee that they may be charged.

#### Zk rollup- Zksync
For now, their server is sequencer
Fee= Off-chain fee + On-chain fee = (storage + SNARK generation) + (Verifying fee + publish fee)
Fee cost:
- $S_t +SNARK$ is off-chain part ($S_t$ is storage fee + SNARK is prover costs):the cost of the state storage and the SNARK (zero-knowledge proof) generation. This part depends on the use of hardware resources and is therefore invariable. Our benchmarks give estimates of ~0.001 USD per transfer.

- $(G_1 +0.4K*n)b_c$ is on-chain part (gas costs): for every zkSync block, the validator must pay Ethereum gas to verify the SNARK ($G_1$), plus additionally ~0.4k gas per transaction to publish the state ∆. The on-chain part is a variable that depends on the current gas price in the Ethereum network. However, this part is orders of magnitude cheaper than the cost of normal ETH/ERC20 transfers

Fee in both Optimism and Zk-roll up separate the fee into L2 and L1 fee (Zksync calls it off chain/ on-chain).

A summary of our research on top three popular roll-up in the market:
| | Revenue | Cost| Profit|
| ------- | -----------------| ---------------- |---------------- |
|Arbitrum|$(G_A*b_A + G_1 * b_{estimated})*1.15+C_p+S$ | $(G_A*b_A + G_1 * b_{p})+C_p+S$|15% on the fee
|Optimism| $0.001*G_U +1.24b_c(G_1+2100)$|$0.001*G_U +1.24b_p(G_1+2100)$ | $1.24(G_1+2100)(b_c-b_p)$
| Zksync|$S_t +SNARK +(G_1 +0.4K*n)b_c$
|Our proposal| $k * G(X) * (f_b + f_{tm} + f_{to})$|$G(X) * (f_{b'} + f_{tm'})$|$k * G(X) * (f_b + f_{tm} + f_{to}) - G(X) * (f_{b'} + f_{tm'})$

Matching the real price models with our model to find the parameters

| | L2 Cost | L1 Cost| Multidimensional |
| ------- | -----------------| ---------------- |---------------- |
|Arbitrum| $G_A * b_A *1.15$| $G_1 *b_{estimated}*1.15$| Yes : $C_p+S$
|Our proposal| | $G(X) * f_C$| No
| Matching parameter| | $C*\sum\limits_{i=1}^ng_i =G_1$; $k=1.15$ if $b_{estimated}=b_c$; $k>1.15$ if $b_{estimated}>b_c$
|Optimism| $0.001*G_U$| $1.24b_c*(G_1+2100)$| No
|Our proposal| $\sum\limits_{i=1}^n (f_i+t_i)$| $C*\sum\limits_{i=1}^n g_i *k*b_c$| No
| Matching parameter| | $C*\sum\limits_{i=1}^ng_i =G_1+2100$; $k=1.24$
|Zksync| |$(G_1 +0.4K*n)b_c$|$S_t + SNARK$
|Our proposal| $\sum\limits_{i=1}^n(f_i+t_i)$| $C*\sum\limits_{i=1}^n g_i *k*b_c$| No
| Matching parameter| | $C*\sum\limits_{i=1}^n g_i=G_1 +0.4K*n$; k=1

# (5/29) convert some of the pending questions to TODOS, iron through 2.6

#### 2.4.3 **Pros and Cons of three ways**
| | Prediction model | Deposite Contract |Current Base Fee|
| ------- | -------------| ---------------- |---|
| Pros |Easy to execute |Avoid Overpayment and send back the extra deposite;High Guarantee|Avoid Overpayment; High Guarantee|
| Cons |Overcharged; Pay for time; Low guarantee; Highly requirement on prediction model accuracy.|There may be existing fraud when send back extra deposit. Trigger more transactions which may cause L2 congestion.|Security Problem; Complexity design

#### (Pending)Question:
1. $C*\sum\limits_{i=1}^n g_i* Y_3-C*\sum\limits_{i=1}^n G_i* Real\_base\_fee$ should this amount profit give to operator or burned?
2. Should consider the L2 bolck rewards?
(Because in the mainchain when the miner publish one block will get reward, we may set the protocol to give the sequencer reward when they successfuly send one batch of transtaction to L1 mempool)

If consider the block rewards and burned the overcharged base fee. The profit model would be:
$Profit=\sum\limits_{i=1}^n t_i + r$

$r$ = reward of the $i_{th}$ batch.

In the profit model only consider tips from L2 users and the reward. The exctra base fee will not give to the sequencer, it will be burnt. Same reason with the EIP 1559, if the base fee is give to sequencer, it may cause the user be overcharged too much.

For the model training, it is supposed to use the transaction fee data from L1. There is another thought that to use the data only from L2 users to predict the future base fee and also to keep track of the users' maxim tips.

In L1, we cannot get the information from mempool, but for L2, when the transactions are sent to L1, we may track these transactions and record the transaction fee if they are linked in L1 . Then it is promising to use this tracing data to predict the future base fee. In addtion, getting information about maxim L2 user's tips from the mempool and related pending time also can help us to specify $f_i$.

In [^6], the author use one-year historical gas price to train Prophet model and the deep learning models, Long-Short Term Memory (LSTM) and Gated Recurrent Unit (GRU). In the end, among these four model, the model accuracy of LSTM could reach 89%. We can conclude that condtructing prediction model is a reliable way to find $kb_c$.

# (5.29) Stashing Deposit Stuff

**Protocol:**

1. L2 users put amount of base fee deposit in L2.
2. L2 users send their transactions to **Deposit Checking** and there two important information are included in their transactions: $F(X)$ and deposit balance($N$).
3. The **Deposit Checking** is uesed for checking the L2 users's deposit balance whether have enough moneny to pay the base fee. For example, the threshold number is setted as 3 times of last L1 base fee (in our diagram is L). If their deposit balance are large than 3L, their transaction will be send to operator. Otherwise, their transaction will be rejected. Once the transaction is sent to operator, the 3L amount deposit will be frozen and the user can not withdraw this amount money.(We even can give deposit checking module more functions such as checking the validation.)
4. Operator collects the transactions and sends them to L1 and pay L1 the base fee at that time directly.
5. Then operator comes back to charge the exactly l1 base fee from the l2 users deposit account.


The **Revenue Model** is seperate two part, before include to l1 and after include:
**Before Include**:
$$ F_1(X) = C_G * g(X) * f_t$$
**After Include:**
$$ H(X) = F_1(X) + g_1(B) * f_C$$

Our **(operator)cost model** is
$$C = G(B) * f_C $$

Our **profit model** is then
$$P = \left(\sum_{i=1}^n H_i\right) - G(B) * f_C.$$
here the $\sum_{i=1}^n g_i(B) = G(B)$

**Simplified Profit Model**
$$P= \sum_{i=1}^n Fi$$

# (5/26) Stashing Part of Section 2 on Examples

#### 2.5.2 Estimation Example 1: 95% confidence upper bound

One simple approach would be to predict $m$

$m$ = predicted base fee for after $T$ seconds.
Because $m$ is predicted number, we want it to be more accuracy, then we generate the 95% upper boud of it.
$Y_2$ = the 95% confidence upper bound of $m$

After getting the $m$, the related models are updated as below:
$R_S=C *(\sum\limits_{i=1}^n g_i)* (Y_2) + \sum\limits_{i=1}^nf_{i} + \sum\limits_{i=1}^n t_i$

$C_S=C *(\sum\limits_{i=1}^n G_i)* f_C + 1/n(\sum\limits_{i=1}^nf_{i})+Slash* \mathbb{1}_{fraud}$

$Profit=C*\sum\limits_{i=1}^n g_i* Y_2-C*\sum\limits_{i=1}^n G_i* Real\_base\_fee+\sum\limits_{i=1}^n t_i-Slash* \mathbb{1}_{fraud}$

When $Y_2 > Real\_base\_fee$, the transction will be linked to L1 and operator will get this amount profit. Otherwise, the transaction will not be linked to L1 and operator will get a portion of $\sum\limits_{i=1}^nt_{i}.$

### 2.4.3 Estimation Example 2: Using current basefee

Proposal 3: Using current base fee as the estimated L1 base fee
In the proposal 1 and 2, we try to find $kc$ and let it satisfies $kc-R \ge 0$ because only $kc-R \ge 0$, miner will accept transaction. In proposol 3, we change the direction and try to let $kc-R \le 0$, which still works. By using current base fee [^8] as $kb_c$, we set the $kb_c$ = $Current Base Fee$. Whenever L2 users send transactions to sequencer, they only pay the current L1 base fee. In the protocol setting, every batch will be sent back to L1 with T seconds. For example, we could let $T$ equals 60 seconds, which means there are four types current base fee in each batch. Under this circumstance, we have four types of current base fee in every batch of transactions:
Setting current base fee at period of 0-15 seconds, 15-30 seconds, 30-45 seconds and 45-60 seconds are $b_{1}$, $b_{2}$, $b_{3}$ and $b_{4}$ respectively.

$R_S=C *[(\sum\limits_{i=1}^n g_i)*b_{1} + (\sum\limits_{i=1}^m g_i)*b_{2} +(\sum\limits_{i=1}^a g_i)*b_{3} +(\sum\limits_{i=1}^c g_i)*b_{4} ]+\sum\limits_{i=1}^nf_{i} +\sum\limits_{i=1}^n t_i$

$C_S=C *(\sum\limits_{i=1}^n G_i)* Real\_base\_fee + \sum\limits_{i=1}^nf_{i}$

$Lost = C *((\sum\limits_{i=1}^n g_i)*b_{1} + (\sum\limits_{i=1}^m g_i)*b_{2} +(\sum\limits_{i=1}^a g_i)*b_{3} +(\sum\limits_{i=1}^c g_i)*b_{4} - \sum\limits_{i=1}^n G_i*Real\_base\_fee)$

Then $kb_{c}$ = $[(\sum\limits_{i=1}^n g_i)*b_{1} + (\sum\limits_{i=1}^n g_i)*b_{2} +(\sum\limits_{i=1}^n g_i)*b_{3} +(\sum\limits_{i=1}^n g_i)*b_{4}]$/$(\sum\limits_{i=1}^n g_i+\sum\limits_{i=1}^m g_i+\sum\limits_{i=1}^a g_i+\sum\limits_{i=1}^c g_i)$

If $kb_c-R \le 0$, the lost is negative otherwise it is positive. No matter whether the $Lost$ is negative or positive, the L2 server takes responsibility for it. It will be automatically counted in the next batch.

Next batch revenue model:

$R_S=C *((\sum\limits_{i=1}^n g_i)*b_{1} + (\sum\limits_{i=1}^m g_i)*b_{2} +(\sum\limits_{i=1}^a g_i)*b_{3} +(\sum\limits_{i=1}^c g_i)*b_{4} +Lost/size) + \sum\limits_{i=1}^nf_{i} +\sum\limits_{i=1}^n t_i$

When the $Lost$ is negative, next generation users in L2 will share the lost. When the $Lost$ is positive, next generation users in L2 will get the reward. The size controls the increasing or reward rate in the model. The size can be fixed or flexible depending on the practical operation data.

According above models, profit for sequencer is:

$Profit = \sum\limits_{i=1}^n t_i$

Sequencer only get benefit from the L2 users tips.

# (5/25) Draft of Section 4

## 4. Interacting with a Multidimensional Fee Market

The pricing model of the multidimensional fee market intention is to shift from having a one dimensionally priced resource with a basefee to now where one basefee exists along with S that can more accurately create a cost in fees based on the Ethereum Virtual Machine's usage. This will also make it easier for operators to try and maximize their profits as the optimization problem shifts from a knapsack problem, into a multivariable equation whose parameters could be accessed from previous blocks in the mainnet.

### 4.1 Multidimensional EIP-1559 Preliminaries

One of the takeaways of EIP-1559 is that it can be thought of as a mechanism that automatically prices many types of resources, most dominantly EVM computation, as a single resource of gas. This concept can be generalized. As an example, real-life computer computations can use different resources (space, time, registers of one type versus another, etc.). Even a specific resource such as time can be split into sub-resources; for example, maybe all computation of a theoretical computer is done in terms of additions and multiplications, which are optimized differently; then it makes sense to split up "computation" into "number of additions" and "number of computations." In summary, we can look at resources that transactions use under higher resolution than just "gas", such as:

- computation: this is the primary resource that gas currently represents
- calldata usage: the block data that serve as parameters to function calls
- storage: writing into EVM storage
- balances changed: the number of balances corresponding to user Ethereum accounts that are changed by a transaction

The main idea of the proposed **multi-dimensional EIP-1559** [^17] design is the following: One can argue that these resources, which are all abstractly currently combined into "gas", all possibly have different limits on their burst (over a short term horizon, such as over one block) and sustained (over a long-term horizon, such as over a year) capacities. Multidimesional EIP-1559 proposes that each of the resources of the Ethereum Virtual Machine be priced seperately; for starters, we can use a different basefee for each resource, and have different slack parameters. The idea is then, the blockchain might be able to better handle situations with different types of demand, especially when the correlations between the different resources are nontrivial.

### 4.2 Multidimensional Pricing Model Proposals for Sequencers

Now to introduce a proposed pricing model; We are interested in the profit of the sequencer and how they can interact with the multidimensional fee market in order to maximize their profit. Thus, we develop a function for the profit $P_s$ that is consisted of a variety of parameters. First off, consider Ethereum blockchain as the current fee market under EIP-1559. As analyzed by Tim Roughgarden, it is the users benefit to post transactions with a "low" basefee, as the user pays less in fees to get the same transaction across (assuming the priority fee was not significant). [^7] Using gas as a single, multi-dimensional priced resource has made this concept simple and easy for users to understand. In the muldimensional fee market, this concept is expanded to greater depths.

First we must take into the account of the addition of **resource fees**, which represents the basefees of all the different priced resources included multidimensional fee market. We can assume users have no individual control over the pricing of any of these resources, and that the basefees cannot in any way be tampered with for an economic advantage. When considering the pricing model for the sequencer, we are still only concerned with the current price of the basefees when interaction with the L1 Ethereum mainnet occurs. So, let $b$ (basefee) $+\sum_{j=1}^\infty{s_j}$ (resource fees) $+f$ (priority fee) represent the total amount of payable fees a user pays to be included in the mainnet. The concept presented by Roughgarden to be implemented in the multidimensional fee market has more parameters to take into account, and as more of these resources become priced, the much more possibilites are taken into account for optimization for fee payment.

#### 4.2.1 Basefee and Resource Fee Optimization on L1

First, we must note that all basefees are still unable to be predicted and that this is merely meant to present how the multidimensional fee market changes the idea of entering the market with a higher or lower than average fee margin. Let us assume that we can label each basefee as "low" or "high" based on a known, average price for a current block on the blockchain. $H$ will represent a high basefee, and $L$ will represent a low basefee. Let us consider the different possibilites of high and low basefees with a distinct number of priced resources below, assuming that the average price of each resource is not a whole number so it cannot be met (For example, imagine if the average basefee was 30.5, and since the current basefee is only expressed as whole numbers, there is no possibility of these numbers matching).
|Number of Priced Resources|High/Low Basefee Combinations|Total Combinations|
|-|-|-|
|0|$H_b,L_b$|2|
|1|$H_bH_1,H_bL_1,L_bH_1,L_bL_1$|4|
|2|$H_bH_1H_2,H_bH_1L_2,H_bL_1H_2,L_bH_1H_2,$ $H_bL_1L_2,L_bH_1L_2,L_bL_1H_2,L_bL_1L_2$|8|
|.|.|.|
|.|.|.|
|.|.|.|
|j|$H_bH_1....H_j,H_bH_1....L_j,...,L_bL_1...H_j,L_bL_1...L_j$|$2^{j+1}$

For each added resource that is priced, there are double the combinations for the price in basefees. Considering the fact that a user perfers to pay the least amount possible, it makes sense that a user would want all "low" basefees so that the summation of all basefees would result in a "low" total amount of basefees paid. However, as another priced resource is added, the likelihood of achieving all low basefees is cut in half, or its probablity being $\frac{1}{2^{j+1}}$. How a sequencer should interact with the multidimensional fee market must look further than posting a batch with all "low" priced resources, as it becomes unrealistic to satisfy those conditions completely. There are multiple ideas to consider for what a user should think about in a multidimensional fee market such as resources having different average basefees, whether each resource is priced independent or dependent of basefee, and if independent, how the different pricing of each resource changes how to interact with the market.

##### 4.2.1.1 Different Average Basefees

Assume that $\overline{b}\neq\overline{s_1}\neq\overline{s_2}\neq...\neq\overline{s_j}$. Therefore, for any percentage increase/decrease for any basefee, the change in amount of cost for each resource will also all be different. For example, let us assume that for the previous block, the price of all basefees dropped ten percent. The highest priced basefee will drop the largest amount of cost, while the smallest basefee drops the least amount of cost. For the user, the largest basefee has more signifigance and should be considered the most when trying to interact with the market for paying less fees.

##### 4.2.1.2 Resource Fees Dependent or Independent of Basefee

The pricing model in the multidimensional fee market for sequencers requires more than one fee to be taken into account, as multpile resources are to be priced. A natural proposal for what the pricing model can look like goes as follows:

$P_s = C * (\sum_{i=1}^n (b_i + (\sum_{j=1}^\infty{s_j}_i)*k -(n*(pb+(\sum_{j=1}^i{(ps)_j}))) -f + \sum_{i=1}^n t_i$

$C$ represents the data compression rate, $b_i$ is the basefee of when each user enters L2, ${s_j}_i$ are all of the priced resource fees of when each user enters L2, $k$ is the percentage fee to be included on L2, $n$ is the number of users, $pb$ is the basefee of when the sequencer submits the batch onto L1, $(ps)_j$ are all of the priced resource fees when the sequencer submits the batch onto L1, $f$ is the priority fee, and $t_i$ is the amount of tips provided to the sequencer. Details are provided below for all the different parameters listed.

#### 4.2.1 Data Compression Rate $C$
The **Data compression** is the compression of total bytes in a transaction or multiple which cuts down on the amount of gas used. [^23] Using less gas will result in a cheaper cost for the sequencer as less data will need to be stored on the Ethereum mainnet, meaning it provides **scalability**. A sequencer can submit a **batch** of multiple or all transaction avaliable at their disposal after compressing the data.[^24] Refer to figure 1 which represents bytes of data used in a simple Ethereum transaction:
| Parameter | Ethereum | Rollup |
|-|-|-|
| Nonce | ~3 | 0 |
| Gasprice |~8 | 0-0.5 |
| Gas | 3 | 0-0.5 |
| To | 21 |4|
| Value | ~9 | ~3 |
| Signature | ~68 (2 + 33 + 33) | ~0.5 |
| From | 0 (recovered from sig) | 4 |
| Total | ~112 | ~12 |

Figure 1 [^19]

All the parameters repesent what makes up of data usage on the mainnet. For a simple Ethereum transaction, the data compression rate would be calculated as $\frac{112}{12}$ or 9.33.

#### 4.2.2 Basefee $b_i$/Resource Fees ${s_j}_i$ of L2 Users
The multi-dimensional fee market makes a total amount of fees $j+1$ where $j$ represents the total amount of resources priced to go along with the original basefee. The resource fees intend to flucuate based on the usage of that specific resource in the previous block, like how basefee does with the total amount of gas currently. However, The resources being priced of the storage fee would be:
| Storage Fee |
|-|
| EVM Execution |
| Tx Calldata |
| Witness Data |
| Storage Size Growth |

Figure 2

These resources can be evaluated by the **block-builders** based on the contents of the block. The storage fee will then be determined by being able to price each of the four resources, and summing them together into one fee for the convience of the users. The basefee will flucuate how it does currently in EIP-1559 based on sizes of the block. Keep in mind that the resources have different sizes and are priced independently of each other, therefore in situations of the same block size but different resources sizes of two different blocks, the basefee would be the same while the storage fee might differ.

#### 4.2.3 Percentage Fee of L2 Inclusion $k$,
This constant is designed for the sequencer to essentially add payment for the users who want to be included in the L2 rollup.[^23] Think of this as paying extra for an upgrade, as the users are able to benefit from using L2 solutions such as having reduced fees from data compression. [^26]

#### 4.2.4 Basefee $pb$/Resource fees $(ps)_j$ for the Sequencer
Variable $n$ signifies the number of users involved in a **batch** once it is submitted onto the Ethereum mainnet. The publication basefee and storage fee represent what the basefee and storage fee are during the submmission. The sequencer is incentivised to submit when these fees are low, however there is no way of predicting when that would happen, just like in the current fee market.

#### 4.2.5 Priority Fee $f$ and Tip $t$
Not much changes for the priority fee and the tips from a current fee pricing model for a sequencer. The sequencer will collect tips from the users included on L2, and also pay a priority fee to have the batch be included on blockchain. Something notable about the two-dimensional fee market is that the boundary cases of block sizes are expected to be much more rare compared to the current fee market.[^17] There is a much lower chance of having to have a high priority fee to be included.

### 4.3 Sequencer Goals For Model

Although the amount of priced resources is unknown and can appear to make maximizing revenue for the sequencer seem difficult, it is important to note that just like gas in the current fee market, it it out of the sequencers control what those parameters will be. It is preferred that all the fees be low when submitting a batch, but there is no way to predict these values, as it would take away from Ethereum being a decenteralized market. The data compression rate is also out of the hands of the sequencer, as the transacion types are submitted by the users which helps determine the data compression rate. We can also assume priority fee and tips to be out of the sequencers hands as well. For just considering the proposed pricing model, this leaves the price of inclusion for users to be included in L2 and the number of transactions in a batch. One thing to note is the sequencer would also prefer to have a lower total cost of fees for a batch submitted than the users average cost of the fees. More details below are provided about how the sequencer can benefit with different values of each parameter.

#### 4.3.1 Publication fee << Average User fee
There is no way of predicting what the future fees will consist of, but something a sequencer does know is the amount of transactions to submit in a batch as well as the average total fee cost was of the transactions.

If $\frac{\sum_{i=1}^n b_i}{n} < p$,
Refer to $R_s = C*(\sum_{i=1}^n b_i*k -(n*p)) -f$, publication fee $p$ has a negative correlation with the revenue of the sequencer $R_s$
$R_s < \sum_{i=1}^n b_i*k -(n*\frac{\sum_{i=1}^n b_i}{n}) -f$
$R_s < (\sum_{i=1}^n b_i)(k-1)-f$ (4) $~~~~~~$ What does this mean?

In order for the sequencer to recoup their costs, the inclusion constant $k$ must be significant.

#### 2. Increasing Number of Transactions

Assume $\frac{\sum_{i=1}^n b_i}{n} = \frac{3}{2}p$ , $k = 1$
| | n = 10 | n = 50 | n = 100 | n = 200 |
|-|-|-|-|-|
| $\frac{\sum_{i=1}^n b_i}{n} = 30$ | $R_s - f = 100$ | $R_s - f = 500$ | $R_s - f = 1000$ | $R_s - f = 2000$
| $\frac{\sum_{i=1}^n b_i}{n} = 36$ | $R_s - f = 120$ | $R_s - f = 600$ | $R_s - f = 1200$ | $R_s - f = 2400$
| $\frac{\sum_{i=1}^n b_i}{n} = 42$ | $R_s - f = 140$ | $R_s - f = 700$ | $R_s - f = 1400$ | $R_s - f = 2800$
| $\frac{\sum_{i=1}^n b_i}{n} = 48$ | $R_s - f = 160$ | $R_s - f = 800$ | $R_s - f = 1600$ | $R_s - f = 3200$

# (5/21) Some paragraphs taht don't belong anymore

To start with an illustrative example, we show how what we call a **deposit contract** can be used to bypass the need to estimate future fee prices in our analysis in Section 2. In other words, this is a slight variant of the basic transaction-inclusion service where the user saves a bit of money from not having to "guess" the increased basefee.

The Ethereum (L1) blockchain is at its heart a state machine that saves state through state transitions encoded in transactions (single state changes) bundled into blocks. Thus, at the end of the day a L2 protocol needs to talk back to L1 and inform L1 of state changes. The responsibility of this is one or more **operators** of L2.

, that is a good approximation and/or upper bound of the fraction $G(X)/g(X)$ over all possible transactions $X$. This is probably the most lossy approximation, for it is possible that the different transaction types have highly varying $G(X)/g(X)$ ratios. Thus, it might be better to approximate it by averaging over empirical distribution of different types of $X$'s. To keep our basic model simple, we can assume this is a good estimate.

# (5/20) 2.4 stash

#### 2.4.1 Finding $f_t$
The tips are incentive to a miner but for users in L2, it is a cost for them. In the **price model**, $f_t$ is a flat additive tip, which could be split into two parts: one is tips to the operator (defined as $f_{to}$) and another is tips for miners (defined as $f_{tm})$. Then,
$$f_t = f_{to} +f_{tm}$$ We first will try to specify $f_{tm}$ by using L1 priority fee (the tips a user need to pay directly to miners if they do not use L2 service). We can just let $f_{tm}$ be a constant and it is set in the protocol. $f_{tm}$ can be equal to:
- the median priority fees (based on history txs in the main chain).
- the predicted tips based on historical tips from L1.

Next, to specify $f_{to}$, we can let it be a variable which depends on the L2 users. The operator will have different **guarantee groups** correpsonding to different ranges for $f_{to}$. The users will choose each range depend on how they care about their transactions getting included. Here are the example of different **guarantee groups** which is desinged by the operator:
- **Low Group**: pay fewer tips with a low guarantee to be published in L1.
- **Median Group**: pay the y median amount of tips with a median guarantee to be published in L1.
- **Fast Group**: pay high tips with high gurantee to be published in L1.
Having the same base fee for L2 and L1 users, if $\sum\limits_{i=1}^nf_{tm} > t_{L1}$, L2 users will beat L1 users where $t_{L1}$ is the tips from L1 user
Finding min($\sum\limits_{i=1}^nf_{tm} - t_{L1}$) could proctect the L2 users' benefit. $\frac{1}{m}(\sum\limits_{i=1}^nf_{tm})=t_{L1}$
$m$ is scaling number. There are three proposals about how to find $f_{tm}$. $m$ will depends on these three setting.

$C_S=C *(\sum\limits_{i=1}^n G_i)* Real\_base\_fee + 1/m(\sum\limits_{i=1}^nf_{i})$

Another way is that the difference in tip is considered as service fee for sequencer.

#### 2.4.2 Finding $k_V$
$f_b$ is current L1 base fee and L2 users are able to know this value. $k_V f_b$ is the base fee L2 users actually pay to sequencer and we denote $k_V f_b$ as a single variable $m$. Our goal is to find $m$ that is approximate $f_C$.
There are three potential ways to find the $m$:
- **Prediction Method**: using machine learning method to build a prediciton model based on historical base fee to predict $m$.
- **Deposit Contract**: L2 users deposit certain amount money to sequencer as the future L1 base fee. Under this situation $m = f_C$
- **Current Base Fee Method**: L2 users only need to pay the current L1 base fee and the L2 server will balance the difference between the current base fee and future base fee. Here are $m = f_C$

In terms of proposal 1 and 2, if $\sum_{i=1}^n F_i. - G(B) * f_C \ge 0$, the sequencer is guaganteed to recoup their cost. The choice of $kv$ is important.
When $m=f_C$, the users pays minumal base fee with high gurantee their transactions will be included in L1

Based on these three proposals, the general revenue model and profit model will change slightly and we will see the detail in each proposal section.

##### 2.4.2.1 Proposal 1--Prediction Model
The one possible way to find $m$ is that using historical L1 transaction fee data to train appropriate machine learning model and use this model to predict $f_C$ and the predicted number is $m$.
How does that work based on current protocol?
We give an example as below figure:

The black solid box is the historical transaction fee data. The prediction model uses these data to predict the future base fee. Since in the protocol design, we have already set every batch sending back time as $T$ seconds. For the main chain, every block will be linked to the main chain for around 15 seconds. Assuming $T$ equals to 60 seconds, for the prediction model, it only needs to predict after 4 blocks base fee and this predicted base fee is what we are finding the $m$. This $m$ will be displayed in the dashboard and users can check it at any time. In addition, the value of $m$ will be renewed once the recent batch has been sent to the main chain. The L2 server responses for this procedure. In [^5], they use the dashboard to renew the gas fee information every 15 seconds.

Hypothetically, once the prediction model is complete, users would know L1 base fee they should pay $m$ and rely on the predicted number.

**Base Fee Model:**
Because the prediction model is not 100% accurate. We buid the base fee model try to improve guarantee.

$m$ = predicted base fee for after $T$ seconds.
$Y_2$ = the 95% confidence upper bound of $Y_1$

#### Revenue Model:
After getting the $m$, the related models are updated as below:
$R_S=C *(\sum\limits_{i=1}^n g_i)* (Y_2) + \sum\limits_{i=1}^nf_{i} + \sum\limits_{i=1}^n t_i$

$C_S=C *(\sum\limits_{i=1}^n G_i)* f_C + 1/m(\sum\limits_{i=1}^nf_{i})+Slash* \mathbb{1}_{fraud}$

$Profit=C*\sum\limits_{i=1}^n g_i* Y_2-C*\sum\limits_{i=1}^n G_i* Real\_base\_fee+\sum\limits_{i=1}^n t_i-Slash* \mathbb{1}_{fraud}$

When $Y_2 > Real\_base\_fee$, the transction will be linked to L1 and operator will get this amount profit. Otherwise, the transaction will not be linked to L1 and operator will get a portion of $\sum\limits_{i=1}^nt_{i}.$

#### (Pending)Question:
1. $C*\sum\limits_{i=1}^n g_i* Y_3-C*\sum\limits_{i=1}^n G_i* Real\_base\_fee$ should this amount profit give to operator or burned?
2. Should consider the L2 bolck rewards?
(Because in the mainchain when the miner publish one block will get reward, we may set the protocol to give the sequencer reward when they successfuly send one batch of transtaction to L1 mempool)

If consider the block rewards and burned the overcharged base fee. The profit model would be:
$Profit=\sum\limits_{i=1}^n t_i + r$

$r$ = reward of the $i_{th}$ batch.

In the profit model only consider tips from L2 users and the reward. The exctra base fee will not give to the sequencer, it will be burnt. Same reason with the EIP 1559, if the base fee is give to sequencer, it may cause the user be overcharged too much.

#### Other Related Thoughts:
For the model training, it is supposed to use the transaction fee data from L1. There is another thought that to use the data only from L2 users to predict the future base fee and also to keep track of the users' maxim tips.

In L1, we cannot get the information from mempool, but for L2, when the transactions are sent to L1, we may track these transactions and record the transaction fee if they are linked in L1 . Then it is promising to use this tracing data to predict the future base fee. In addtion, getting information about maxim L2 user's tips from the mempool and related pending time also can help us to specify $f_i$.

#### Conclusion
In [^6], the author use one-year historical gas price to train Prophet model and the deep learning models, Long-Short Term Memory (LSTM) and Gated Recurrent Unit (GRU). In the end, among these four model, the model accuracy of LSTM could reach 89%. We can conclude that condtructing prediction model is a reliable way to find $kb_c$.

##### 2.4.2.2 Proposal 2--- Deposit Contract
In this proposal, L2 users deposit the base fee on L2 and later the operator will charge l1 base fee from their deposit account. Since the operator know that the l2 users have enough deposit to pay them, at the begining, the operator does not charge the l2 users l1 base fee instead the operator only charges the base fee after they sent the transaction to l1. At that time, the operator know how much exact base fee they should charge from the deposit account. Then they will come back to charge the l2 users from their deposit account. In order to better under the whole processure, we list extra protocol as below:
**Protocol:**

1. L2 users put amount of base fee deposit in L2. They choose how much should be deposite.
2. L2 users send their transactions to **Deposit Checking** Function and there two important information are included in their transactions: $F(X)$ and deposite balance($N$).
3. The **Deposit Checking** is uesed for checking the L2 users's deposit balance whether have enough moneny to pay the base fee. For example, the threshold number is setted as 3 times of last L1 base fee (in our diagram is L). If their deposit balance are large than 3L, their transaction will be send to operator. Otherwise, their transaction will be sent back. Once the transaction send to operator, the 3L amount deposit will be frozen and the user can not withdraw this amount money.(We even can give this module more function such as checking the validation)
4. Operator collect the transaction and send them to L1 and pay L1 the base fee at that time directly.
5. Then operator comes back to charge the exactly l1 base fee from the l2 users deposit account.


The **Revenue Model** is seperate two part, before include to l1 and after include:
**Before Include**:
$$ F_1(X) = C_G * g(X) * f_t$$
**After Include:**
$$ H(X) = F_1(X) + g_1(B) * f_C$$

Our **(operator)cost model** is
$$C = G(B) * f_C $$

Our **profit model** is then
$$P = \left(\sum_{i=1}^n H_i\right) - G(B) * f_C.$$
here the $\sum_{i=1}^n g_i(B) = G(B)$

**Simplified Profit Model**
$$P= \sum_{i=1}^n Fi$$

For this proposal avoids estimating the l1 base fee. The operator profit only comes from the l2 users tips. The tips related to the gas used, it has the positive relationship with the gas used.

**Next Part Belong to Refund System**
In Deposit Contract, we let users in L2 to guess the future transaction fee and pay this guessed base fee as the deposit to operator. In this proposal, $kb_c$ exactly equal to future base fee, since the base fee will deduct in future.
Part 1: There are extra restrictions that should be put in the protocol
1. The user needs to pay amount of deposit to the operator, which will be used to pay the future base fee. How much should L2 users pay that decides by the L2 users' estimations.
2. The deposit will not reuse for the users' next transaction. For next transaction, users should pay another amount deposit again.
3. Users in L2 will send the transaction to operator. This transaction includes： transaction information + deposit + tips(L1) + service fee(to sequencer).
4. Sequencer binds transactions then send the batch of transactions to L1. The miners will follow the EIP 1559 to charge the base fee and collect the tips.
5. If the deposit is higher than the current base fee, the overcharged part will be sent back to users in L2. If the base fee is lower than the current base fee, it will be pending in the mempool, until the base fee matches the deposit. If users are eager to make a successful transaction, they need to pay a higher deposit.

Part 2: Methods to estimate L1 base fee

Users will enter the L1 base fee by themselves (there is no estimation fee-no fixed L1 base fee from operator). However, to have a constraint on the amount of base fee input by users, operator will have an information table with the type of guarantees differ for each group of users. Depending on the urge of getting their transaction included in L1, the users will need to following the base fee range for each group of transactions. Below is the explaination on why we want to seperate the txs and how to cluster them.

- Why should we separate the txs into different groups?

Since the operator will send one batch transaction to L1 and this one batch transaction will be treated as one transaction by miner. The picture below demostrates a case where a user who put high base fee and high tip, but their txs was delayed because another user from the same batch pay less fee. To solve the problem, we think of customizing the deposit into different groups.


- How to cluster the txs

Users with high tips and high deposit will be grouped in High-High group. Second group is Medium-High (medium deposit, high tip). Third group is High-Medium and last group is Low-Low (for the combinations other than the first 3 groups). The operator then will batch the transactions that fall in the same category and send each batch to the mempool in L1. High-High group will be sent first, then Medium-High, High-Medium and Low-Low. It will help solve the problem that people who pay less but their transaction get included at the same as users who give high deposit and tips.


We want to set a range for each group, so that the users when they input their deposits and tips, they would know which group they belong to. That means, if they want their transactions to be included fast, they will give high deposit and high tips to the operator.
Let's see one example (For simplicity, we assumed that all the transactions are same in size, types and require same amount of gas used)

User 2 wants his transaction to be finished quickly, so he puts high deposit and high tips for the operator (the values fall into the high-high range). Hence, it got include first. Similar for the other transactions.
One questions arise here is that how can we decide the range for each group and how can we scale it when the transactions are different in size and gas used?

##### 2.4.2.3 Proposal 3: Using current base fee as the estimated L1 base fee
In the proposal 1 and 2, we try to find $kc$ and let it satisfies $kc-R \ge 0$ because only $kc-R \ge 0$, miner will accept transaction. In proposol 3, we change the direction and try to let $kc-R \le 0$, which still works. By using current base fee [^8] as $kb_c$, we set the $kb_c$ = $Current Base Fee$. Whenever L2 users send transactions to sequencer, they only pay the current L1 base fee. In the protocol setting, every batch will be sent back to L1 with T seconds. For example, we could let $T$ equals 60 seconds, which means there are four types current base fee in each batch. Under this circumstance, we have four types of current base fee in every batch of transactions:
Setting current base fee at period of 0-15 seconds, 15-30 seconds, 30-45 seconds and 45-60 seconds are $b_{1}$, $b_{2}$, $b_{3}$ and $b_{4}$ respectively.

$R_S=C *[(\sum\limits_{i=1}^n g_i)*b_{1} + (\sum\limits_{i=1}^m g_i)*b_{2} +(\sum\limits_{i=1}^a g_i)*b_{3} +(\sum\limits_{i=1}^c g_i)*b_{4} ]+\sum\limits_{i=1}^nf_{i} +\sum\limits_{i=1}^n t_i$

$C_S=C *(\sum\limits_{i=1}^n G_i)* Real\_base\_fee + \sum\limits_{i=1}^nf_{i}$

$Lost = C *((\sum\limits_{i=1}^n g_i)*b_{1} + (\sum\limits_{i=1}^m g_i)*b_{2} +(\sum\limits_{i=1}^a g_i)*b_{3} +(\sum\limits_{i=1}^c g_i)*b_{4} - \sum\limits_{i=1}^n G_i*Real\_base\_fee)$

Then $kb_{c}$ = $[(\sum\limits_{i=1}^n g_i)*b_{1} + (\sum\limits_{i=1}^n g_i)*b_{2} +(\sum\limits_{i=1}^n g_i)*b_{3} +(\sum\limits_{i=1}^n g_i)*b_{4}]$/$(\sum\limits_{i=1}^n g_i+\sum\limits_{i=1}^m g_i+\sum\limits_{i=1}^a g_i+\sum\limits_{i=1}^c g_i)$

If $kb_c-R \le 0$, the lost is negative otherwise it is positive. No matter whether the $Lost$ is negative or positive, the L2 server takes responsibility for it. It will be automatically counted in the next batch.

Next batch revenue model:

$R_S=C *((\sum\limits_{i=1}^n g_i)*b_{1} + (\sum\limits_{i=1}^m g_i)*b_{2} +(\sum\limits_{i=1}^a g_i)*b_{3} +(\sum\limits_{i=1}^c g_i)*b_{4} +Lost/size) + \sum\limits_{i=1}^nf_{i} +\sum\limits_{i=1}^n t_i$

When the $Lost$ is negative, next generation users in L2 will share the lost. When the $Lost$ is positive, next generation users in L2 will get the reward. The size controls the increasing or reward rate in the model. The size can be fixed or flexible depending on the practical operation data.

According above models, profit for sequencer is:

$Profit = \sum\limits_{i=1}^n t_i$

Sequencer only get benefit from the L2 users tips.

#### 2.4.3 **Pros and Cons of three ways**
| | Prediction model | Deposite Contract |Current Base Fee|
| ------- | -------------| ---------------- |---|
| Pros |Easy to execute |Avoid Overpayment and send back the extra deposite;High Guarantee|Avoid Overpayment; High Guarantee|
| Cons |Overcharged; Pay for time; Low guarantee; Highly requirement on prediction model accuracy.|There may be existing fraud when send back extra deposit. Trigger more transactions which may cause L2 congestion.|Security Problem; Complexity design

### 2.5 Market research

We did a research on practical L2 networks: Optimisms, Arbitrum (Optimistic) and Zksync (Zk rollup) to know their protocals and their pricing models. This section is to compare their protocal, the sequencers' roles in each network. And lastly, their revenue model for sequencers vs our proposed model.

Purpose:
- What is the mainly different between the Arbitrum and Optimism.
- How many roles are involved in the platforms.
- Which processrues involved the cost and revenue.

#### 2.5.1 Protocal comparison:
| | Arbitrum |Optimism|Zk-Rollup|
| ------- | -----------|----------|--------------|
|Type|Optimistic Rollup|Optimistic Rollup|Rollup
|Proof|Fraud Proof; Multi-round proofs|Fraud Proof;Single-round proof|zero knowledge proof
|Validation Time|At least 7 days| 7 days|Instant|
|Virtual Machine|AVM|OVM [^10]|Some don't have EVM support|
|Reduction of Gas Cost|50x to 270x|up to 10x|
|Gas Price| |L1 and L2 gas prices at that time (If the L1 gas price spikes, Optimism pays the new cost. [^8]|may cost only a few cents[^15]|

#### 2.5.2 Sequencers' Roles Comparison:

| | Aggregator | Sequencer(our model) |Challenger|
| ------- | -----------------| ---------------- |--------|
| Responsibility |Wrap the tx and sent them to the on-chain smart contract|Collecting and compressing the tx then send the main chian|Verifying the tx and compute state pubilished by the aggregators.|
|How to become|Anyone send a deposit to the on-chain smart contract|Anyone send a deposit to the on-chain smart contract|Anyone who post their own bond and challenge the assertion|
|Compensation|Pay by users, include in the transaction|Pay by users, include in the trasaction|The deposit of the aggregator|
|Punishment|Deposit will be slashed|Apart of compensation will be slashed| Lose their bond

Punishment: If fraud is successfully proven, a X% of deposit gets burned and the remaining (1-X)% gets distributed proportionally to every user that provided data for the fraud proof.

#### 2.5.3 Current Revenue model (for Optimitic Rollup)

#### Arbitrum
fee= L2 fee + L1 fee
$G_A *b_A= L2\; fee$: a base fee for each L2 transaction, to cover the cost of servicing a transaction. The base price $(b_A)$ of an L2 transaction is set by each aggregator, using an Arbitrum precompile, subject to a system-wide maximum.

$b_A \ge \frac{b_{estimated}}{100}$: The minimum ArbGas price is set equal to the estimated L1 gas price divided by 100. The price of ArbGas will never go lower than this.

$G_1 * b_{estimated}$ is L1 calldata: a fee per units of L1 calldata directly attributable to the transaction (as on Ethereum, each non-zero byte of calldata is 16 units, and each zero byte of calldata is 4 units).The base price of a unit of L1 calldata is just the estimated L1 gas price

ArbGas: the cost of a computation on Arbitrum.

Users can choose to submit their transactions through an aggregator or not. Besides the L2 tx and L1 calldata fee, users in Arbitrum also need to pay computation fee: a fee per unit of ArbGas used by the transaction and
storage fee: a fee per location of EVM contract storage, based change in EVM storage usage due to the transaction.
#### Optimism

fee= L2 fee + L1 fee

$0.001*G_U$ is L2 execution fee= tx.gasPrice * l2GasUsed
where tx.gasPrice is usually 0.001 gwei, but might change depend on the congestion Optimism dashboard [^10]. l2GasUsed = the amount of computation and storage that they use.

$1.24b_c(G_U+2100)$ is L1_data_fee = L1_gas_price * (tx_data_gas + fixed_overhead) * dynamic_overhead

The L1 data fee based on four factors:

1. L1_gas_price = the current gas price on Ethereum (at most the user will pay no more than 25% expected) [^8]
2. tx_data_gas = the gas cost to publish the transaction to Ethereum. This scales roughly with the size of the transaction (in bytes).
(tx_data_gas = count_zero_bytes(tx_data) * 4 + count_non_zero_bytes(tx_data) * 16)
4. fixed_overhead: Cost denominated in gas. The cost of adding a transaction to a batch decreases as the total batch size increases.This is currently set to 2100 [^8].
5. A dynamic overhead cost which scales the L1 fee paid by a fixed number. This is currently set to 1.24 (This value covers the change in L1 gas price between the time the transaction is submitted and when it is published, as well as the income we need to keep our system running).

The previous fixed overhead and dynamic overhead were 2750 and 1.5 which means Optimism was able to reduce the cost up to 30% [^8]

Users are not able to set limits for the L1 data fee that they may be charged.

#### Zk rollup- Zksync
For now, their server is sequencer
Fee= Off-chain fee + On-chain fee = (storage + SNARK generation) + (Verifying fee + publish fee)
Fee cost:
- $S_t +SNARK$ is off-chain part ($S_t$ is storage fee + SNARK is prover costs):the cost of the state storage and the SNARK (zero-knowledge proof) generation. This part depends on the use of hardware resources and is therefore invariable. Our benchmarks give estimates of ~0.001 USD per transfer.

- $(G_1 +0.4K*n)b_c$ is on-chain part (gas costs): for every zkSync block, the validator must pay Ethereum gas to verify the SNARK ($G_1$), plus additionally ~0.4k gas per transaction to publish the state ∆. The on-chain part is a variable that depends on the current gas price in the Ethereum network. However, this part is orders of magnitude cheaper than the cost of normal ETH/ERC20 transfers

Fee in both Optimism and Zk-roll up separate the fee into L2 and L1 fee (Zksync calls it off chain/ on-chain).

A summary of our research on top three popular roll-up in the market:
| | Revenue | Cost| Profit|
| ------- | -----------------| ---------------- |---------------- |
|Arbitrum|$(G_A*b_A + G_1 * b_{estimated})*1.15+C_p+S$ | $(G_A*b_A + G_1 * b_{p})+C_p+S$|15% on the fee
|Optimism| $0.001*G_U +1.24b_c(G_1+2100)$|$0.001*G_U +1.24b_p(G_1+2100)$ | $1.24(G_1+2100)(b_c-b_p)$
| Zksync|$S_t +SNARK +(G_1 +0.4K*n)b_c$
|Our proposal| $C(\sum\limits_{i=1}^n g_i) (k*b_c)$ $+ \sum\limits_{i=1}^n f_i +\sum\limits_{i=1}^n t_i$| $C (\sum\limits_{i=1}^n G_i) b_p + f$|$C \Big{[}kb_c \sum\limits_{i=1}^n g_i-b_p\sum\limits_{i=1}^n G_i \Big{]} + \sum\limits_{i=1}^n f_i -f +\sum\limits_{i=1}^n t_i-Slash \mathbb{1}_{fraud}$

Matching the real price models with our model to find the parameters

| | L2 Cost | L1 Cost| Multidimensional |
| ------- | -----------------| ---------------- |---------------- |
|Arbitrum| $G_A * b_A *1.15$| $G_1 *b_{estimated}*1.15$| Yes : $C_p+S$
|Our proposal| $\sum\limits_{i=1}^n (f_i+t_i)$| $C*\sum\limits_{i=1}^n g_i *k*b_c$| No
| Matching parameter| | $C*\sum\limits_{i=1}^ng_i =G_1$; $k=1.15$ if $b_{estimated}=b_c$; $k>1.15$ if $b_{estimated}>b_c$
|Optimism| $0.001*G_U$| $1.24b_c*(G_1+2100)$| No
|Our proposal| $\sum\limits_{i=1}^n (f_i+t_i)$| $C*\sum\limits_{i=1}^n g_i *k*b_c$| No
| Matching parameter| | $C*\sum\limits_{i=1}^ng_i =G_1+2100$; $k=1.24$
|Zksync| |$(G_1 +0.4K*n)b_c$|$S_t + SNARK$
|Our proposal| $\sum\limits_{i=1}^n(f_i+t_i)$| $C*\sum\limits_{i=1}^n g_i *k*b_c$| No
| Matching parameter| | $C*\sum\limits_{i=1}^n g_i=G_1 +0.4K*n$; k=1

# (5/16) Reference List Stash

## Reference Stuff

### reading refrence storage to be integrated
[txref]

[30] <blog.mycrypto.com/new-transaction-types-on-ethereum> "tx types 1559 distinction"

[conditional transfer+liquidity prover]
[conditional transfer+liquidity prover]: <https://www.cryptoninjas.net/2021/03/09/deversifi-introduces-fast-withdrawals-feature-between-l2-and-l1-ethereum/>

[L2 interoperability]
[L2 interoperability]: (https://hackernoon.com/layer2-interoperability-starkex-vs-loopring-vs-hermez-vs-connext-5y1p37vs )
[additional conditional tx]
[additional conditional tx]: (https://medium.com/starkware/conditional-transfers-the-key-to-interoperability-2e1de044fb65 )

[]: <https://www.sciencedirect.com/science/article/pii/S2096720921000257> atomic crosschain tx for side

[]: <https://dydx.exchange/blog/alpha> L2 roadmap dydx

[]: <https://eprint.iacr.org/2018/046.pdf> Ben-Sasson, Eli, Iddo Bentov, Yinon Horesh, and Michael Riabzev. "Scalable, transparent, and post-quantum secure computational integrity." Cryptology ePrint Archive (2018).
used for summary and distinction of proof types for L2

[]: <https://vitalik.ca/general/2017/11/09/starks_part_1.html,
https://vitalik.ca/general/2017/11/22/starks_part_2.html,
https://vitalik.ca/general/2018/07/21/starks_part_3.html>
Vitalik’s STARKs implemntation and benefits presentation

[]: <https://help.optimism.io/hc/en-us/articles/4411895794715> optimism fee structure

[]: <https://medium.com/ethereum-optimism/the-road-to-sub-dollar-transactions-part-2-compression-edition-6bb2890e3e92> optimism outline post

[]: <https://eprint.iacr.org/2019/360.pdf> overview L2 protocols

[]: <https://upcommons.upc.edu/handle/2117/359879> masters thesis providing overview of L1 L2, data availability motivating optimistic and zk.

https://ethereum.org/en/developers/docs/scaling/validium/

[]: <https://ethereum.org/en/developers/docs/evm/opcodes/>
https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a2-sha3
https://jellopaper.org/evm/#access-list-gas

other
https://cryptorobin.com/what-is-proof-of-history/
https://anycoindirect.eu/en/blog/what-is-proof-of-history
https://academy.solflare.com/what-is-proof-of-history/

nocite
https://doseofdefi.substack.com/p/bridging-to-a-multi-chain-defi-world?s=r broad

https://get2knowcrypto.net/zksnarks-vs-zkstarks-key-differences/ snark stark difference overview

https://en.wikipedia.org/wiki/Non-interactive_zero-knowledge_proof

Arbitrum [fee](https://developer.offchainlabs.com/docs/inside_arbitrum#fees)
Optimisim, [online link](https://community.optimism.io/docs/developers/build/transaction-fees/#understanding-the-basics)
C. A. Roger, "Analysis and development of blockchain rollups," Master's thesis, Universitat Politècnica de Catalunya, 2021.
M. Patrick, C. Buckland, B. Yee and D. Song. "SoK: Validating Bridges as a Scaling Solution for Blockchains." Cryptology ePrint Archive, 2021.
The Optimistic Layer 2 Wars, [online link](https://adlrocha.substack.com/p/adlrocha-the-optimistic-layer-2-wars?s=r).
[Zksync](https://docs.zksync.io/userdocs/tokens.html#fee-costs)

# (5/16) Old Problem 3 old table

------ STASH here on are slide remnants probably not in

### base table storage

|type of guarantee|Implementation|requirements/potential overheads|target audience/existing implementation|Sequencer overhead type vs regular transaction (not considering above service identification)|
|---|---|---|---|---|
|Anonymization|Varying degrees, simplist is only recording tx record not details on L1|implementation dependent some degree given by zk, also methods that don’t store data on L1| high value tx, tx with possibility of being front run, non simple tx **[x]**|Computational|
|L2 confirmation|Generates a message on/off chain to an address when the sequencer does an attempt at including the tx in a batch|message after L1 posting returned to users|urgent tx that may be canceled, cautious users|Comunication, small storage overhead|
|L2 confirmed|Sequencer generates a token that is sent to the user with signed a batch #. If the tx is not recorded in L2 and appearing on L1 the user can submit the token on L1 and recieve a slashing reward | <!-- message w/token after sequencer decides to include that proscribes a L2 batch # so a user that is not included after that point can slash the sequencer. --> Generating the token and returning it are overhead to the sequencer and requires user monitoring. | any user wanting tracking, commerce, high value tx that want to be sure things occur|Token generation and communication
|Escape hatch|L1 smart contracts running L2 support user generated proof of some L2 ownership that allows L2=>L1 fund transfer|requires some increased complexity for zk rollups, more so for optimistic, increases cost of setting up initial L2 smart contracts on L1 but need not increase tx overhead|safety concious users, users interested in riskier/newer L2s, used by many zk rollups and some optimistic, if L1 is truly agnostic this is a strong guarantee **[x]**|smart contract creation at l2 setup / can be overhead in ceasing through put for some implementations|
|Atomic tx|Sequencer accepts and processes either all of the tx in the same batch or is able to be slashed. User must label the pieces of the transactions (Potentially sequencer within distributed context) |The sequencer can package the tx with overhead of verifying all the flagged tx are together. (easiest is require all tx be flagged that are grouped, MEV allowing is more costly as groupings are less distinct). Alternatively can add more overhead in some implementations as the sequencer must first verify all the tx will go through in the proposed state of the block or be open to slashing. |users with knowledge but low funds, MEV finders,zkopru and hermez **[x]** |Computational, Verification and sorting overhead|
|Grouped tx|atomic but also sequential|can be a modest overhead based on number of tx, sequencer can to some extent just treat them like one large tx with 1 gas value and 1 price. most of the cost would be opportunity|MEV, apps trying to sequence calls, maybe easier verification for users if paying back a group|Computational
|Recurring tx|The sequencer accepts a set of transaction where the transaction is repeated is succesive blocks as user selects|adds off chain storage cost to sequencer depending on size and time constraints, can be verified after the fact that something is in sequential batches. Risky the longer time period is offered if strict guarantee. Increased tx size so that inclusion of all batched tx is verifiable. similar would be delayed or slow below|Support of anonymizing protocols, running smart contracts, proof of livliness | Storage
|Slow tx/lower cost|Somewhat a default behavior, this allows explicit binning for user and sequencer.|Adds offchain storage cost to sequencer but may allow them to profit off the priority fee difference over the time period. User is trading paying the storage cost for letting the sequencer place it freely but in a bounded batch#.(so distinct in that the user is getting a guarantee it will be by some batch number.) So the sequencer is also required to do some predictive work|non urgent users, cost concious users, large numbers of unordered simple tx.|Storage, maybe computational(could also reduce)|
|Delayed tx|User defines a time or batch number after which they want the next batch to include their tx. Longer times require price increases or better prediction|Adds offchain storage cost, risk of L1 priority fee increases, cost of generating a token for the user(for strong guarantee). opportunity cost of inclusion at the later block for other tx.[alternatively just allow users to specify batch # for tx w/o guarantee of inclusion]|more complicated trading/MEV, L2 apps(games or automated payments like billpay)|Storage|
|Order tx|User can specify tx that are |Adds need for additional market or prefrence ordering|MEV, more complicated L2 apps **[x]** |coordination overhead|
|Sequenced Tx|sender fixes number tx and any number can be included over batches but must be in order|Sequencer now needs to verify order and store tx if not done at once|If L3 is going to be supported or other recurrsive rollups sequence guarantees would ease implementation|storage computation|

# (5/16) Old Problem 3 Section 1

## Problem 3 Rollups and Guarantees

**In this section/problem/topic have generated some new ideas about transaction types and looked at which are already implemented. We have also looked specifically at how lazy evaluation might be brought to ethereum L2's noting the potentially high cost of implementation as well as some cases where it makes more sense.**

We examine what **services** can be (and are) offered by an L2 sequencer. Services are offers of specific outcomes involving the process of including the transaction on L2 or how it will be recorded on L1. Here we primarily look at services that can be observed on the L2 chain and are thus able to be held **accountable**. Accountable means that if actions are taken that violate the rules of L2 the sequencer can be punished. The two primary methods of enforcement are fraud proofs and validity proofs.

**Fraud proofs** are 'optimistic'. This means the associated L2's assume that in the normal course of things sequencers and L2 users will behave(sequencers take responsibility for L2 users when they publish an L2 batch). There is a record of the L2 state that is observable on Ethereum L1, so if anyone sees an infraction, a punishment can be assigned to the sequencer based on the severity of the infraction. This means that users of the L2 must watch the recorded L2 state or that other people must be incentivized to check that the L2 state is reached with valid steps. The fraud proof itself consists of showing the state A before the infraction, the operation o that was bad and the state that should have been reached after o(A).[^14]

**Validity proofs** work by proving that the sequencer knows that a particular state is true before they publish a batch. They prove that they know a state is correct and follows the rules by outputting from a function that takes the L2 information as inputs. This output is then published with the L2 state on L1. This means that creating false transactions before hand is difficult by some probability, a metric set by the specific L2 protocol. The validity proof itself usually consists of a merkle tree consisting of verified transactions that have been divided into a batch.[^14]

Both styles of proof serve to establish a basis for trusting the Sequencer. When a user puts money into an L2 that doesnt have any method of ensuring the rules are followed then they are essentially back to a reputation based system, which distributed ledgers are fundamentally trying to get away from.

The different types of L2 will get some consideration as the type of L2 effects what kind of guarantees can be made. The types are differentiated along the axes of fraud/verification proofs and data availability.

| |Data available|Data off-chain|
|---|---|---|
|**Fraud proofs**|Optimistic rollups|PLASMAs|
|**Validity proof**|Zero-Knowledge rollups|Validium|

Here **data available** means from the perspective of an L1 user the L2 state is fully recoverably recorded. **Data off-chain** means that the full L2 state is not available from L1. An off-chain L2 uses a hash or some similar highly compressed that represents it on L1. There is much greater scaling with L2's that store data off- chain. At some point lossless compression is optimal and greater scaling will require off chain storage[^9]. From these L1 records we see that the security of L2 is based on the security of L1 Ethereum, if the record(of L2) on L1 can be changed(is insecure) then L2 is no longer secure either.

Currently, most L2's with offchain data and Validity proof based systems are primarily based off of simple transactions(including token transfers). However recently Scroll published a full Zero Knowledge EVM so that limitation is more development limited than structural[^10]. This does not directly impact what guarantees can be offered but does change the population of who would be interested in what.
We will be focusing on data available rollups but note where implementations closer to a full sidechain are applicable.

L2 is being looked at due to the growing cost of transactions on ethereum. In order for L2 rollups to be adopted as a solution for scaling there must be guarantees, so that users can have an expectation of behavior. The types of guarantees are targeted by the creator of the L2, users can then match their needs with the distinct L2 properties. This is important as L2 rollups rely on Ethereum for security as opposed to sidechain based. As L2 roll ups are still distributed ledgers, the system must ensure that there a sufficient

(We will focus on data available L2 rollups, optimistic and zero-knowledge. Data availablity allows for lighter L2 implementations and in particular maniplation of L2 state from L1.)

# (5/15) Things I may want to add

- $F_P$: this is a fee given to the operator *from the protocol itself*, acting as a per-batch constant award (a natural generalization, for example, would be a variable award based on activity)

# (5/15) Old Problem 2 Model

Our main **revenue** model is:

$$R_S=C *(\sum\limits_{i=1}^n g_i)* (k*b_c) + \sum\limits_{i=1}^n f_i +\sum\limits_{i=1}^n t_i.$$
In this list:
- $C$: the compression rate. The smaller the C, the better for both sequencers and users.
- $g_i$: estimated gas cost if $tx_{i}$ happens in L1. In [^4], author introduces that the gas calculation method of the transaction will be affected by multiple factors such as the user's address, transaction complexity, short-term price fluctuations, and L2 lag, it can only be used as a reference.
- $k$: $k$ is a rate that reflects the fluctuation of the base fee. It depends on different proposals.
- $b_c$ :estimated L1 Base Fee
- $f_i$: tips offer to miners from user i.
- $t_i$: user i's inclusion tip (for sequencer). It is artribary by the users
- $n:$ number of users

#### 2.3.2 Cost Model:
$C_S=C *(\sum\limits_{i=1}^n G_i)* b_p + f +Slash* \mathbb{1}_{fraud}$
$G_i$: real size
$b_p$: Publication fee when the batch is added

(note that it is possible, especially in regimes where computation is costly/hidden, to include the cost of slashing or frauds in the cost model. For our basic model, we can assume that the operator has enough bandwidth to simulate the EVM computation and avoid frauds altogether)

#### 2.3.3 Profit Model
$Profit=C *\Big{[}kb_c *\sum\limits_{i=1}^n g_i-b_p*\sum\limits_{i=1}^n G_i \Big{]} + \sum\limits_{i=1}^n f_i -f +\sum\limits_{i=1}^n t_i-Slash* \mathbb{1}_{fraud}$

#### 2.3.4 Model Example

Example: This example consider the simplest case where all the txs are the same (like they require the same gas cost and the estimations are the same as the actual values)
Let's say there are around 200 pending txs in mempool and a sequencer wants to batch 100 of these txs and send them to L1 within blocks. The saftest choice of k for the sequencer is 2 (which means the sequencer can recoup their cost and also can guagantee that users' txs will be included). Let's say the current base fee is 20 gwei/gas. And the publication base fee when the batch is published is still 20 (the future base fee is either increase or stay the same, but not reduce???)-I chose 20 to reflect the case where the sequencer seems to overcharge the users (worst scenario for users). Assuming that the compression rate is $C=\frac{1}{100}$ and each tx will cost $21,000$ units of gas. Each user tips Sequencer same amount 100 gwei

| | Revenue | Cost | Profit|
| ------- | -----------------| ---------------- | ------|
|base fee | $\frac{1}{100}*(100*21,000)*2*20$ $=840,000$ gwei| $\frac{1}{100}*(100*21,000)*20$ $=420,000$|
|f=200 gwei| 100*200=20000 gwei| 200 gwei|
|$\sum\limits_{i=1}^n t_i$ $=10000 gwei$| 10,000 gwei|0|
|fraud=0| | 0| |
|Total| 870,000| 420,200|449,800

Questions: 1. Risk Sequencer takes: If fraud=1, the cost will increase (how much usually is the slash?)
2. Tip?

Let's stand on User perspective to see why they should use sequencer (what is the benefit of using L2 for users):

| | Supposed to pay | Actual pay | Saving|
| ------- | -----------------| ---------------- | ------|
|base fee | $21,000* 20 (b_p)=42,000 gwei$| $\frac{1}{100}*21000*40=8400 gwei$| 33,600|
|f=200 gwei| 200 gwei| 200 gwei|0|
|$t_i$| 0|100|-100|
|Total|42300 | 8700|33600|

### 2.4 Paremeter Specification
#### 2.4.1 Finding $f_i$
In the **price model**, the variable $f_i$ is tips from L2 user i and will give to the miner in L1. The tips are incentive to a miner but for users in L2 it is a cost for them. There are two different perspectives to treat $f_i$.
1. $f_i$ is a constant and it is set in the protocol. For L2 users, it is a given number and this number could be referred to as:
- $f_i$ = the median priority fees (based on history txs in the main chain).
- $f_i$ = predicted tips based on historical tips from L1.
2. $f_i$ is a variable and depends on the L2 users. After paying different tips, the L2 users will be assigned to different guarantee groups by operator, such as:
**Low Group**: pay fewer tips with a low guarantee to be published in L1.
**Median Group**: pay the y median amount of tips with a median guarantee to be published in L1.
**Fast Group**: pay high tips with high gurantee to be published in L1.
Having the same base fee for L2 and L1 users, if $\sum\limits_{i=1}^nf_{i} > t_{l1}$, L2 users will beat L1 users.
$t_{l1}$ = the tips from L1 user
Finding min($\sum\limits_{i=1}^nf_{i} - t_{l1}$) could proctect the L2 user benefit. $1/m(\sum\limits_{i=1}^nf_{i})=t_{l1}$
$m$ is scaling unmber. There are three proposals about how to find $f_{i}$. $m$ will depends on these three setting.

$C_S=C *(\sum\limits_{i=1}^n G_i)* Real\_base\_fee + 1/m(\sum\limits_{i=1}^nf_{i})$

Another way is that the difference in tip is considered as service fee for sequencer.

#### 2.4.2 Finding $kb_c$
$b_c$ is current L1 base fee and L2 users are able to know this value. $kb_c$ is the base fee L2 users actually pay to sequencer. The parameter $k$ refelcts the fluctuation of $b_c$.
There are three potential ways to find the $kc$:
- **Prediction Method**: using machine learning method to build a prediciton model based on historical base fee to predict $k_{bc}$.
- **Deposit Contract**: L2 users deposit certain amount money to sequencer as the future L1 base fee.
- **Current Base Fee Method**: L2 users only need to pay the current L1 base fee and the L2 server will balance the difference between the current base fee and future base fee.

Based on these three proposals, the general revenue model and profit model will change slightly.
In terms of proposal 1 and 2, if $kb_c *\sum\limits_{i=1}^n g_i-b_p*\sum\limits_{i=1}^n G_i \ge 0$, the sequencer is guaganteed to recoup their cost. The choice of k is important.

##### 2.4.2.1 Proposal 1--Prediction Model
The one possible way to find $kb_{c}$ is that using historical L1 transaction fee data to train appropriate machine learning model and use this model to predict $kb_{c}$.
How does that work based on current protocol?
We give an example as below figure:

The black solid box is the historical transaction fee data. The prediction model uses these data to predict the future base fee. Since in the protocol design, we have already set every batch sending back time as $T$ seconds. For the main chain, every block will be linked to the main chain for around 15 seconds. Assuming $T$ equals to 60 seconds, for the prediction model, it only needs to predict after 4 blocks base fee and this predicted base fee is what we are finding the $kb_{c}$. This $kb_{c}$ will be displayed in the dashboard and users can check it at any time. In addition, the value of $kb_{c}$ will be renewed once the recent batch has been sent to the main chain. The L2 server responses for this procedure. In [^5], they use the dashboard to renew the gas fee information every 15 seconds.

Hypothetically, once the prediction model is complete, users would know L1 base fee they should pay $kb_{c}$ and rely on the predicted number.

**Base Fee Model:**
Because the prediction model is not 100% accurate. We buid the base fee model try to improve guarantee.

$Y_1$ = predicted base fee for after $T$ seconds.
$Y_2$ = the 95% confidence upper bound of $Y_1$

#### Revenue Model:
After getting the $kb_c$, the related models are updated as below:
$R_S=C *(\sum\limits_{i=1}^n g_i)* (Y_2) + \sum\limits_{i=1}^nf_{i} + \sum\limits_{i=1}^n t_i$

$C_S=C *(\sum\limits_{i=1}^n G_i)* Real\_base\_fee + 1/m(\sum\limits_{i=1}^nf_{i})+Slash* \mathbb{1}_{fraud}$

$Profit=C*\sum\limits_{i=1}^n g_i* Y_2-C*\sum\limits_{i=1}^n G_i* Real\_base\_fee+\sum\limits_{i=1}^n t_i-Slash* \mathbb{1}_{fraud}$

When $Y_2 > Real\_base\_fee$, the transction will be linked to L1 and operator will get this amount profit. Otherwise, the transaction will not be linked to L1 and operator will get a portion of $\sum\limits_{i=1}^nt_{i}.$

#### (Pending)Question:
1. $C*\sum\limits_{i=1}^n g_i* Y_3-C*\sum\limits_{i=1}^n G_i* Real\_base\_fee$ should this amount profit give to operator or burned?
2. Should consider the L2 bolck rewards?
(Because in the mainchain when the miner publish one block will get reward, we may set the protocol to give the sequencer reward when they successfuly send one batch of transtaction to L1 mempool)

If consider the block rewards and burned the overcharged base fee. The profit model would be:
$Profit=\sum\limits_{i=1}^n t_i + r$

$r$ = reward of the $i_{th}$ batch.

In the profit model only consider tips from L2 users and the reward. The exctra base fee will not give to the sequencer, it will be burnt. Same reason with the EIP 1559, if the base fee is give to sequencer, it may cause the user be overcharged too much.

#### Other Related Thoughts:
For the model training, it is supposed to use the transaction fee data from L1. There is another thought that to use the data only from L2 users to predict the future base fee and also to keep track of the users' maxim tips.

In L1, we cannot get the information from mempool, but for L2, when the transactions are sent to L1, we may track these transactions and record the transaction fee if they are linked in L1 . Then it is promising to use this tracing data to predict the future base fee. In addtion, getting information about maxim L2 user's tips from the mempool and related pending time also can help us to specify $f_i$.

#### Conclusion
In [^6], the author use one-year historical gas price to train Prophet model and the deep learning models, Long-Short Term Memory (LSTM) and Gated Recurrent Unit (GRU). In the end, among these four model, the model accuracy of LSTM could reach 89%. We can conclude that condtructing prediction model is a reliable way to find $kb_c$.

##### 2.4.2.2 Proposal 2--- Deposit Contract

In Deposit Contract, we let users in L2 to guess the future transaction fee and pay this guessed base fee as the deposit to operator. In this proposal, $kb_c$ exactly equal to future base fee, since the base fee will deduct in future.
Part 1: There are extra restrictions that should be put in the protocol
1. The user needs to pay amount of deposit to the operator, which will be used to pay the future base fee. How much should L2 users pay that decides by the L2 users' estimations.
2. The deposit will not reuse for the users' next transaction. For next transaction, users should pay another amount deposit again.
3. Users in L2 will send the transaction to operator. This transaction includes： transaction information + deposit + tips(L1) + service fee(to sequencer).
4. Sequencer binds transactions then send the batch of transactions to L1. The miners will follow the EIP 1559 to charge the base fee and collect the tips.
5. If the deposit is higher than the current base fee, the overcharged part will be sent back to users in L2. If the base fee is lower than the current base fee, it will be pending in the mempool, until the base fee matches the deposit. If users are eager to make a successful transaction, they need to pay a higher deposit.

Part 2: Methods to estimate L1 base fee

Users will enter the L1 base fee by themselves (there is no estimation fee-no fixed L1 base fee from operator). However, to have a constraint on the amount of base fee input by users, operator will have an information table with the type of guarantees differ for each group of users. Depending on the urge of getting their transaction included in L1, the users will need to following the base fee range for each group of transactions. Below is the explaination on why we want to seperate the txs and how to cluster them.

- Why should we separate the txs into different groups?

Since the operator will send one batch transaction to L1 and this one batch transaction will be treated as one transaction by miner. The picture below demostrates a case where a user who put high base fee and high tip, but their txs was delayed because another user from the same batch pay less fee. To solve the problem, we think of customizing the deposit into different groups.


- How to cluster the txs

Users with high tips and high deposit will be grouped in High-High group. Second group is Medium-High (medium deposit, high tip). Third group is High-Medium and last group is Low-Low (for the combinations other than the first 3 groups). The operator then will batch the transactions that fall in the same category and send each batch to the mempool in L1. High-High group will be sent first, then Medium-High, High-Medium and Low-Low. It will help solve the problem that people who pay less but their transaction get included at the same as users who give high deposit and tips.


We want to set a range for each group, so that the users when they input their deposits and tips, they would know which group they belong to. That means, if they want their transactions to be included fast, they will give high deposit and high tips to the operator.
Let's see one example (For simplicity, we assumed that all the transactions are same in size, types and require same amount of gas used)


User 2 wants his transaction to be finished quickly, so he puts high deposit and high tips for the operator (the values fall into the high-high range). Hence, it got include first. Similar for the other transactions.
One questions arise here is that how can we decide the range for each group and how can we scale it when the transactions are different in size and gas used?

##### 2.4.2.3 Proposal 3: Using current base fee as the estimated L1 base fee
In the proposal 1 and 2, we try to find $kc$ and let it satisfies $kc-R \ge 0$ because only $kc-R \ge 0$, miner will accept transaction. In proposol 3, we change the direction and try to let $kc-R \le 0$, which still works. By using current base fee [^8] as $kb_c$, we set the $kb_c$ = $Current Base Fee$. Whenever L2 users send transactions to sequencer, they only pay the current L1 base fee. In the protocol setting, every batch will be sent back to L1 with T seconds. For example, we could let $T$ equals 60 seconds, which means there are four types current base fee in each batch. Under this circumstance, we have four types of current base fee in every batch of transactions:
Setting current base fee at period of 0-15 seconds, 15-30 seconds, 30-45 seconds and 45-60 seconds are $b_{1}$, $b_{2}$, $b_{3}$ and $b_{4}$ respectively.

$R_S=C *[(\sum\limits_{i=1}^n g_i)*b_{1} + (\sum\limits_{i=1}^m g_i)*b_{2} +(\sum\limits_{i=1}^a g_i)*b_{3} +(\sum\limits_{i=1}^c g_i)*b_{4} ]+\sum\limits_{i=1}^nf_{i} +\sum\limits_{i=1}^n t_i$

$C_S=C *(\sum\limits_{i=1}^n G_i)* Real\_base\_fee + \sum\limits_{i=1}^nf_{i}$

$Lost = C *((\sum\limits_{i=1}^n g_i)*b_{1} + (\sum\limits_{i=1}^m g_i)*b_{2} +(\sum\limits_{i=1}^a g_i)*b_{3} +(\sum\limits_{i=1}^c g_i)*b_{4} - \sum\limits_{i=1}^n G_i*Real\_base\_fee)$

Then $kb_{c}$ = $[(\sum\limits_{i=1}^n g_i)*b_{1} + (\sum\limits_{i=1}^n g_i)*b_{2} +(\sum\limits_{i=1}^n g_i)*b_{3} +(\sum\limits_{i=1}^n g_i)*b_{4}]$/$(\sum\limits_{i=1}^n g_i+\sum\limits_{i=1}^m g_i+\sum\limits_{i=1}^a g_i+\sum\limits_{i=1}^c g_i)$

If $kb_c-R \le 0$, the lost is negative otherwise it is positive. No matter whether the $Lost$ is negative or positive, the L2 server takes responsibility for it. It will be automatically counted in the next batch.

Next batch revenue model:

$R_S=C *((\sum\limits_{i=1}^n g_i)*b_{1} + (\sum\limits_{i=1}^m g_i)*b_{2} +(\sum\limits_{i=1}^a g_i)*b_{3} +(\sum\limits_{i=1}^c g_i)*b_{4} +Lost/size) + \sum\limits_{i=1}^nf_{i} +\sum\limits_{i=1}^n t_i$

When the $Lost$ is negative, next generation users in L2 will share the lost. When the $Lost$ is positive, next generation users in L2 will get the reward. The size controls the increasing or reward rate in the model. The size can be fixed or flexible depending on the practical operation data.

According above models, profit for sequencer is:

$Profit = \sum\limits_{i=1}^n t_i$

Sequencer only get benefit from the L2 users tips.

#### 2.4.3 **Pros and Cons of three ways**
| | Prediction model | Deposite Contract |Current Base Fee|
| ------- | -------------| ---------------- |---|
| Pros |Easy to execute |Avoid Overpayment and send back the extra deposite;High Guarantee|Avoid Overpayment; High Guarantee|
| Cons |Overcharged; Pay for time; Low guarantee; Highly requirement on prediction model accuracy.|There may be existing fraud when send back extra deposit. Trigger more transactions which may cause L2 congestion.|Security Problem; Complexity design