For the complete documentation index, see llms.txt. This page is also available as Markdown.

Performance Benchmark

Why performance benchmarks matter

In gaming and prediction systems, performance is not an abstract metric. It directly impacts:

  • Player experience (latency, responsiveness)

  • Fairness and determinism (state updates, settlement order)

  • Operational cost (fees, batching, retries)

  • System scalability under real load

For this reason, PlayBlock benchmarks itself not only against other Layer-2 and Layer-3 chains, but against the actual requirements of high-frequency, real-money gaming settlement.

Traditional benchmarks that focus only on peak TPS or theoretical throughput are insufficient. What matters is sustained performance under load, with deterministic execution and predictable costs.

What we measure

PlayBlock evaluates performance using metrics that reflect real production behavior:

Core metrics

  • Block time How frequently blocks are produced.

  • Transaction inclusion latency Time from submission to block inclusion (p50 / p95).

  • Sustained throughput Transactions per second under continuous load, not short bursts.

  • Cost per action Measured for:

    • Native transfers

    • ERC-20 transfers

    • Game actions (contract calls with state changes + events)

  • Finality model

    • Local finality (on PlayBlock itself)

    • Upstream settlement finality (parent chain / Ethereum)

  • Data availability (DA) model Ethereum DA vs AnyTrust / DAC-based DA and its impact on cost and latency.

Benchmarking philosophy

PlayBlock does not attempt to “win” benchmarks by tuning for synthetic workloads. Instead, benchmarks are designed to reflect real Playnance production flows, including:

  • Gasless user transactions

  • High-frequency game actions

  • Deterministic ordering requirements

  • Continuous execution over long periods

This makes comparisons more honest and directly relevant to developers and operators.

High-level comparison overview

Network Type
Typical Block Time
Throughput Characteristics
Finality Model
Gaming Suitability

PlayBlock (L3, AnyTrust RAAS)

Sub-second (configurable)

Optimized for sustained, high-frequency game actions

Fast local finality, Ethereum-anchored

Purpose-built for gaming settlement

General-purpose L2s

~2–4 seconds

High, but shared across many applications

Rollup-based L1 finality

Good for general DeFi, less optimized for games

ZK-based L2s

~2–4 seconds

High theoretical throughput, proof-bound

Proof-dependent finality

Strong security, higher latency for settlement

App-specific L3s

Sub-second to 1s

Configurable per application

Parent-chain dependent

Good when tightly scoped

Key takeaway: PlayBlock optimizes for predictable latency and deterministic execution, not just maximum TPS.

Why PlayBlock performs differently

1. Purpose-built execution model

PlayBlock is not a shared execution environment for unrelated applications. It is designed specifically for:

  • Games

  • Predictions

  • Casino-style interactions

  • Settlement-heavy workflows

This allows aggressive tuning of:

  • Block intervals

  • Gas limits

  • Sequencer behavior

  • State access patterns

2. Layer-3 architecture on Arbitrum + AnyTrust

PlayBlock operates as a Layer-3 application chain using:

  • Arbitrum Orbit stack

  • AnyTrust data availability

This enables:

  • Significantly lower data costs

  • Faster block production

  • Higher sustained throughput for small, frequent transactions

The tradeoff is explicit and intentional: PlayBlock prioritizes performance and cost efficiency while maintaining Ethereum-anchored security guarantees.

3. Gasless execution for users

End users do not pay gas directly.

This removes several performance bottlenecks present on public L2s:

  • No user-side gas estimation delays

  • No mempool competition

  • No priority fee bidding wars

From a benchmark perspective, this results in:

  • More stable inclusion times

  • Predictable cost per action

  • Cleaner latency distributions

4. Deterministic settlement first

In gaming, determinism beats raw speed.

PlayBlock enforces:

  • Strict ordering of actions

  • Deterministic settlement logic

  • Clear separation between:

    • User-visible confirmation

    • Upstream settlement finality

This makes benchmarks more meaningful for real money systems.

To ensure fair comparison, PlayBlock benchmarks follow a consistent structure:

Workloads tested

  1. Native token transfer

  2. ERC-20 transfer

  3. Game action (state update + event emission)

Load profile

  • Gradual ramp-up (e.g. 50 → 500 → 2,000 tx/s)

  • Sustained load per level (10–20 minutes)

  • Measurement of:

    • p50 / p95 latency

    • Error / revert rate

    • Effective throughput

    • Cost per transaction

Reporting principles

  • Separate local confirmation from L1 finality

  • Report sustained numbers, not peaks

  • Publish configuration parameters alongside results

Interpreting benchmark results correctly

When comparing PlayBlock to other chains, it is critical to understand:

  • A 2s block time on a general L2 does not imply worse UX if pre-confirmation is used

  • A sub-second block time does not guarantee deterministic settlement

  • “Finality” can mean different things depending on the rollup or proof system

PlayBlock benchmarks are designed to answer one question:

Can this system reliably settle high-frequency, real-money game actions at scale?

Summary

PlayBlock’s performance profile is the result of deliberate architectural choices:

  • Layer-3 app-chain design

  • AnyTrust data availability

  • Gasless execution

  • Deterministic settlement focus

Rather than competing on marketing TPS numbers, PlayBlock optimizes for what actually matters in production gaming systems: low latency, predictable costs, and reliable settlement under sustained load.

Last updated

Was this helpful?