Logo
ScienceStack
Table of Contents
Fetching ...
Sign In

Perils of Parallelism: Transaction Fee Mechanisms under Execution Uncertainty

Sarisht Wadhwa, Aviv Yaish, Fan Zhang, Kartik Nayak

Abstract

Modern blockchains increasingly rely on parallel execution to improve throughput. We show several industry and academic transaction fee mechanisms (TFMs) struggle to simultaneously account for execution parallelism while remaining performant and fair. First, if parallelism affects fees, adversarial protocol manipulations that offset possible benefits to throughput by introducing fake transactions become rational: users can insert functionally useless parallel transactions solely to reduce fees, and schedulers can create useless sequential transactions to increase revenue. Execution contingency, a core feature of expressive programming languages, both exacerbates the aforementioned threats and introduces new ones: (1) users may overpay for unused resources, and (2) scheduler revenue is harmed when reserved scheduling slots go unused due to contingency. We introduce a framework for this challenging setting, and prove an impossibility, highlighting an inherent tension: both parallelism and contingency involve a trade-off between minimizing risks for users and schedulers, as favoring one comes at the expense of the other. To complete the picture, we introduce a fee mechanisms and prove that they achieve the boundaries of this trade-off. Our results provide rigorous foundations for evaluating designs advanced by notable blockchains, such as Sui and Monad.

Perils of Parallelism: Transaction Fee Mechanisms under Execution Uncertainty

Abstract

Modern blockchains increasingly rely on parallel execution to improve throughput. We show several industry and academic transaction fee mechanisms (TFMs) struggle to simultaneously account for execution parallelism while remaining performant and fair. First, if parallelism affects fees, adversarial protocol manipulations that offset possible benefits to throughput by introducing fake transactions become rational: users can insert functionally useless parallel transactions solely to reduce fees, and schedulers can create useless sequential transactions to increase revenue. Execution contingency, a core feature of expressive programming languages, both exacerbates the aforementioned threats and introduces new ones: (1) users may overpay for unused resources, and (2) scheduler revenue is harmed when reserved scheduling slots go unused due to contingency. We introduce a framework for this challenging setting, and prove an impossibility, highlighting an inherent tension: both parallelism and contingency involve a trade-off between minimizing risks for users and schedulers, as favoring one comes at the expense of the other. To complete the picture, we introduce a fee mechanisms and prove that they achieve the boundaries of this trade-off. Our results provide rigorous foundations for evaluating designs advanced by notable blockchains, such as Sui and Monad.

Paper Structure

This paper contains 63 sections, 10 theorems, 49 equations, 1 figure, 1 table.

Table of Contents

  1. Introduction
  2. Peril 1: Contingent Transactions and Risk.
  3. Risk Allocation Mechanisms.
  4. Peril 2: Shill attacks on Gas Consumption Mechanisms.
  5. Shill attacks with Contingent Transactions.
  6. Object-Weighted Transaction Fee Mechanism.
  7. Contributions.
  8. Outline
  9. Related Work
  10. Parallel Execution and Blockchain Scalability.
  11. Transaction Fee Mechanisms (TFMs).
  12. Gas Computation in Parallel Settings.
  13. Scheduling and Complexity.
  14. Model
  15. Transactions.
  16. ...and 48 more sections

Key Result

Lemma 1

For any transaction ${tx}\xspace$, initial state $s\xspace$ and schedule $\mathcal{S}\xspace$, then the sum of $\mathrm{UR}\xspace$ and $\mathrm{SR}\xspace$ is constant, independent of the execution of the transaction. $\blacktriangleleft$$\blacktriangleleft$

Figures (1)

  • Figure 1: Comparison of scheduling strategies and their object usage.

Theorems & Definitions (41)

  • Definition 1: User Risk
  • Definition 2: Scheduler Risk
  • Lemma 1: Risk tradeoffs
  • proof
  • Lemma 2
  • proof
  • Theorem 1
  • proof
  • Remark 1
  • Definition 3: Object Usage Machine (OUM)
  • ...and 31 more