Gas Throughput Analysis

This document provides gas throughput estimates for the chain under various hardware configurations and execution modes.

Current Gas Configuration

Parameter	Default Value	Notes
target_gas_per_block	15,000,000	EIP-1559 target (50% of max)
max_gas_per_block	30,000,000	Hard cap per block
min_base_fee	1	Floor for dynamic pricing
max_base_fee	10,000,000	Ceiling for dynamic pricing
base_fee_change_denominator	8	EIP-1559 adjustment rate

Configuration defined in src/core/mod.rs via GasPricingConfig.

Gas Schedule Summary (gas-v1)

Opcode Costs

Category	Gas	Examples
ALU	1	add, sub, xor, and, or
Shift/Bitmanip	2	sll, srl, sra, rotates
Branch/Jump	2	jal, jalr, conditionals
Multiply	5	mul, mulh variants
Divide/Remainder	20	div, rem variants

Memory Costs

Operation	Gas	Notes
Load warm stack/rodata	2	Aligned access
Load cold stack/rodata	6	First touch
Load warm heap/data	4	Aligned access
Load cold heap/data	10	First touch
Store warm stack	2	-
Store warm heap/data	6	-
Store cold heap/data	12	First touch
Page fault (first touch)	50	Per 4KB page
Dirty page (first write)	10	Per page
Predecode per byte	1	Basic block parsing

Syscall Costs

Syscall	Base Gas	Per 32B	Notes
storage_read_warm	200	+4	Warm slot
storage_read_cold	600	+8	Cold slot
storage_write	400	+8	Any write
call	500	+4 in/out	Cross-contract
static_call	400	+4 in/out	Read-only call
emit_log	150	+4 data, +20/topic	Event emission
keccak256	800	+20	Hash precompile
sha2_256	800	+20	Hash precompile
blake3	400	+10	Hash precompile
verify_sig	6000	+20	Signature verification
create	2000	+20	Contract deployment

Full schedule in docs/gas-schedules/gas-v1.json.

Hardware Reference Configuration

Test Configuration: 16 cores, 32GB RAM, 4TB NVMe SSD

This represents a mid-range validator/RPC node setup.

Throughput Estimates

Transaction Gas Profiles

Transaction Type	Typical Gas	Notes
Native transfer	~21,000	Base tx cost
ERC20 transfer	~50,000-65,000	2 storage writes
AMM swap	~150,000-200,000	Multiple reads/writes
Complex DeFi	~300,000-500,000	Multiple calls
Contract deploy (small)	~500,000-1,000,000	Code size dependent

Throughput by Execution Mode

Mode	Max Gas/Block	Est. TPS	Bottleneck
Sequential (current)	30M	200-300	Single-core VM
Block-STM (planned)	100-150M	600-1000	Conflict rate
Optimistic ceiling	200M	1500+	I/O, consensus

Detailed Analysis

Sequential Execution (Current)

• CPU: RISC-V interpreter runs ~30-50M gas/sec on single core
• Storage: Not bottlenecked; NVMe handles 500K+ IOPS
• Memory: 32GB sufficient for hot state cache
• Consensus: Simplex single-slot finality at 1s blocks is not limiting

Recommendation: Keep max_gas_per_block at 30M.

Parallel Execution (Block-STM, Planned)

Block-STM enables optimistic parallel execution with conflict detection:

• Effective parallelism: 3-5x on typical DeFi workloads
• Conflict-free workloads: Up to 8-12x theoretical
• High-conflict workloads: Falls back to sequential

Current status: Execution is still sequential (SimpleExecutionEngine applies blocks in order). The prerequisites for Block-STM exist (access lists, per-transaction state journaling, deterministic rollback), but the parallel scheduler + MVCC validation loop is not implemented yet. The design lives in docs/design/block-stm-parallel-execution.md and is deferred until throughput constraints demand it.

Recommendation: After Block-STM implementation, increase to 100M gas/block.

Bottleneck Breakdown

Resource	Capacity	At 30M gas/block	At 100M gas/block
CPU (sequential)	~50M gas/sec	60% utilized	Bottleneck
CPU (parallel, 16 cores)	~200M gas/sec	15% utilized	50% utilized
NVMe IOPS	500K/sec	~15% (75K writes)	~50% (250K writes)
Memory bandwidth	~100GB/s	<1%	<5%
Network (consensus)	1 block/sec	Not limiting	Not limiting

Storage Growth Projections

At sustained max throughput (30M gas/block):

Metric	Value	Notes
Max storage writes/block	75,000	30M / 400 gas per write
Write rate	~7.5 MB/sec	Assuming 100B avg value
Daily growth	~650 GB	At 100% utilization
4TB SSD lifespan	~6 days	Without pruning

Note: Real-world utilization is typically 10-30% of max, and state pruning/compaction is required for long-term operation.

Testing Max Gas Configuration

To test different gas limits:

# Run devnet with custom gas config
ASHEN_MAX_GAS_PER_BLOCK=50000000 just devnet-small

# Monitor block gas usage
just rpc-call chain_getBlock '{"height": "latest"}' | jq '.gas_used'

# Stress test with batch transactions
cargo run --release -p ashen --bin ashen -- \
  batch execute --count 1000 --gas-limit 100000

Metrics to Monitor

1. Block execution time: Should stay under block time (1s)
2. Gas utilization: gas_used / max_gas_per_block
3. State growth rate: Monitor disk usage
4. Mempool depth: Indicates demand vs capacity

Recommended Configuration by Use Case

Use Case	max_gas	target_gas	Block Time	Notes
Testnet	30M	15M	1s	Default, conservative
Production (sequential)	30M	15M	1s	Current implementation
Production (Block-STM)	100M	50M	1s	After parallel execution
High-throughput L2	150M	75M	500ms	Requires tuning

References

• Gas schedule: docs/gas-schedules/gas-v1.json
• Gas pricing config: src/core/mod.rs (GasPricingConfig)
• VM gas metering: crates/vm-gas/src/lib.rs
• Execution engine: src/core/execution/mod.rs