Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Define standard L2 Transaction Fee Structure #23

Closed
Therecanbeonlyone1969 opened this issue May 29, 2022 · 7 comments
Closed

Define standard L2 Transaction Fee Structure #23

Therecanbeonlyone1969 opened this issue May 29, 2022 · 7 comments

Comments

@Therecanbeonlyone1969
Copy link
Collaborator

In connection with issue #21 it is necessary to accommodate different fee structures and how they are calculated across L2s.

Define a new Ethereum transaction type with execution on Layer 2 and what data needs to be published to Layer 1.

@bossyuansu
Copy link

also the transparency of the pricing. So far L2s are presenting the fees to the user in different ways.

@Therecanbeonlyone1969
Copy link
Collaborator Author

Can we define a basic fee structure e.g.:

  • base fee -> minimal fee to cover node operation
  • execution fee -> cost for executing a transaction
  • priority fee -> fee to pay to validators/sequencers to move to the front of the execution queue
    ?

@DZGoldman
Copy link
Contributor

Can give the details with respect to Arbitrum:
Arbitrum tx fees comprise 2 dimensions: the L2 fee (L2 base fee * L2 gas limit) + the L1 fee (price per unit of L1 data * estimated L1 calldata used). This ultimately gets surfaced by RPCs to conform to the fee structure described in the previous comment, for ease of client side integration, as such:

  • base fee: l2 gas price; responds to L2 congestion ala L1 Ethereum. Has a set floor price (0.1 gwei on Arbitrum One as of writing).
  • "execution fee": value that when multiplied by base fee will be sufficient to cover both the L2 and L1 fees; i.e.,
    L2 gas limit + ( L1 fee) / (L2 gas price)
  • priority fee: currently a noop; moving forward / with decentralized sequencing, the current thinking is that it will by the tx ordering priority within a fixed "fairness granularity" time-window; see here

@Therecanbeonlyone1969
Copy link
Collaborator Author

Transaction Feee definitions completed and PR #34 merged

@Therecanbeonlyone1969
Copy link
Collaborator Author

Therecanbeonlyone1969 commented Mar 22, 2023

Type of requirements needed for specification:

  • define transaction
  • define roles for fee visibility -- tx originator, tx sender (might be intermediary), developer, L2 operator
  • define transaction types: direct transactions (tx originator to L2), meta-transactions (intermediary to L2),
  • give transaction examples on tx originator and intermediary (focus on control by tx originator(s) on intermediary)
  • give examples of types of control -> note that control can move between entities
  • requirements on intermediaries to create fee visibility
  • intermediary transactions as internal transactions
  • require full fee transparency from the intermediary on fees charged to the intermediary for the tx originator
  • explain why we might have zero fees (meta-transactions)
  • fee communication to end-users and developers -- how, when, and where
  • fee estimates
  • final fees
  • final fees vs fee estimates
  • reorgs (challenged trxns in optimistic rollups, non finalized blocks in zk-rollups) --> what happens with paid fees? Reimbursed? Lost?

Out of scope: L2 <-> L2 bridge fees (separate workitem), Fees between L2s and centralized exchanges

@Therecanbeonlyone1969
Copy link
Collaborator Author

See PR #43 for a first full draft of the transaction fee specification

@Therecanbeonlyone1969
Copy link
Collaborator Author

Closing issue for now after merging PR #43

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants