Logo
ScienceStack
Table of Contents
Fetching ...
Sign In

Groundhog: Linearly-Scalable Smart Contracting via Commutative Transaction Semantics

Geoffrey Ramseyer, David Mazières

TL;DR

Groundhog introduces a deterministic, linearly scalable smart-contract engine that executes blocks of unordered, concurrent transactions by using commutative, typed storage modifications and a reserve-commit mechanism. Reads occur from a single block-start snapshot, and most side-effects are commutative, allowing per-key batched application with minimal synchronization. The system supports arbitrary WebAssembly contracts via a flexible storage API (bytestrings, nonnegative integers, ordered sets) and includes robust handling for irresolvable conflicts via constraints, ensuring deterministic block results while maintaining high throughput. Groundhog demonstrates practical finance-oriented applications (tokens, auctions, money markets) and achieves near-linear scaling on multi-core hardware, with throughput exceeding hundreds of thousands of payments per second, underscoring its potential for large-scale deployments such as wCBDCs.

Abstract

Groundhog is a novel design for a smart contract execution engine based around concurrent execution of blocks of transactions. Unlike prior work, transactions within a block in Groundhog are not ordered relative to one another. Instead, our key design insights are first, to design a set of commutative semantics that lets the Groundhog runtime deterministically resolve concurrent accesses to shared data. Second, some storage accesses (such as withdrawing money from an account) conflict irresolvably; Groundhog therefore enforces validity constraints on persistent storage accesses via a reserve-commit process. These two ideas give Groundhog a set of semantics that, while not as powerful as traditional sequential semantics, are flexible enough to implement a wide variety of important applications, and are strictly more powerful than the semantics used in some production blockchains today. Unlike prior smart contract systems, transactions throughput never suffers from contention between transactions. Using 96 CPU cores, Groundhog can process more than half a million payment transactions per second, whether between 10M accounts or just 2.

Groundhog: Linearly-Scalable Smart Contracting via Commutative Transaction Semantics

TL;DR

Groundhog introduces a deterministic, linearly scalable smart-contract engine that executes blocks of unordered, concurrent transactions by using commutative, typed storage modifications and a reserve-commit mechanism. Reads occur from a single block-start snapshot, and most side-effects are commutative, allowing per-key batched application with minimal synchronization. The system supports arbitrary WebAssembly contracts via a flexible storage API (bytestrings, nonnegative integers, ordered sets) and includes robust handling for irresolvable conflicts via constraints, ensuring deterministic block results while maintaining high throughput. Groundhog demonstrates practical finance-oriented applications (tokens, auctions, money markets) and achieves near-linear scaling on multi-core hardware, with throughput exceeding hundreds of thousands of payments per second, underscoring its potential for large-scale deployments such as wCBDCs.

Abstract

Groundhog is a novel design for a smart contract execution engine based around concurrent execution of blocks of transactions. Unlike prior work, transactions within a block in Groundhog are not ordered relative to one another. Instead, our key design insights are first, to design a set of commutative semantics that lets the Groundhog runtime deterministically resolve concurrent accesses to shared data. Second, some storage accesses (such as withdrawing money from an account) conflict irresolvably; Groundhog therefore enforces validity constraints on persistent storage accesses via a reserve-commit process. These two ideas give Groundhog a set of semantics that, while not as powerful as traditional sequential semantics, are flexible enough to implement a wide variety of important applications, and are strictly more powerful than the semantics used in some production blockchains today. Unlike prior smart contract systems, transactions throughput never suffers from contention between transactions. Using 96 CPU cores, Groundhog can process more than half a million payment transactions per second, whether between 10M accounts or just 2.
Paper Structure (52 sections, 6 figures, 2 algorithms)

This paper contains 52 sections, 6 figures, 2 algorithms.

Table of Contents

  1. Introduction
  2. Our Contribution: Groundhog
  3. Architecture Overview
  4. Managing Concurrent Writes
  5. Deployment Context
  6. Design Properties
  7. Deterministic Operation
  8. Parallel Proposal and Execution
  9. Semantic Flexibility
  10. Robustness to Malicious Contracts
  11. Design Motivation
  12. Storage Semantics
  13. Bytestrings
  14. Nonnegative Integers
  15. Constraint: Nonnegativity
  16. ...and 37 more sections

Figures (6)

  • Figure 1: A sample of applications implementable in Groundhog, and the changes required by Groundhog's model.
  • Figure 2: Transactions per second on Groundhog, varying the number of accounts ("acc") and batch size ("bch").
  • Figure 3: Transactions per second on Block-STM gelashvili2023block, varying the number of accounts ("acc") and batch size ("bch").
  • Figure 4: Transactions per second on Groundhog with batches of size 100,000, varying the number of accounts.
  • Figure 5: Transactions per second on Block-STM with batches of size 100,000, varying the number of accounts.
  • ...and 1 more figures