---
# System prepended metadata

title: '[EARLY DRAFT] Prover killer opcodes: a data-driven analysis'

---

# [EARLY DRAFT] Prover killer opcodes: a data-driven analysis

## Introduction

[Costs to prove Ethereum blocks are down only](https://x.com/soispoke/status/1892528208957821345).  [Competing zkVMs](https://ethproofs.org/) have drastically improved their performance over the past few years, with many predicting that proving Ethereum blocks in real time (under 12 seconds) will become a practical reality by 2025. However, if Ethereum is to rely on provers in the [not-so-distant future](https://www.youtube.com/watch?v=lRqnFrqpq4k), rigorous research is needed to determine whether certain EVM instructions (i.e., opcodes and precompiles) are particularly slow or computationally intensive to prove. 

In this post, we use a data-driven approach to identify "prover killer" blocks with particularly long proving times, and then analyze the opcode-level gas consumption patterns to pinpoint the specific opcodes that contribute most to these performance bottlenecks.

## Methods

### Data Acquisition and Preprocessing

- Proofs and associated metadata—including clusters, AWS instance pricing, and zkVM teams—were extracted from Supabase ethproofs.org data. This data was then used to calculate key derived metrics such as proving time and proving costs for each block.
- Opcode execution traces were obtained via Ethereum's debug_traceTransaction RPC call using Xatu. These traces provided the sequence of opcodes executed along with their gas consumption, allowing us to compute the total real gas used and the execution frequency for each opcode per block.

These datasets were merged to obtain a unified dataset that links each block's proving performance with granular opcode-level gas usage metrics, enabling the identification and analysis of prover killer blocks.

### Prover Killer Block Detection
To identify prover killer blocks, we used a regression-based outlier detection method. Blocks were first grouped by team and day, and a linear regression model was used to capture the relationship between gas usage and proving time. Blocks with residuals exceeding three stds from the regression line were flagged as prover killers. Each flagged block (N=256) was then matched with a non-prover killer block based on similar gas usage within a 10% tolerance to ensure accurate comparisons.

### Machine Learning Pipeline
A Random Forest classifier was trained to predict prover killer blocks using the aggregated opcode features. Hyperparameters were tuned via grid search with stratified k-fold cross-validation. Feature importance was evaluated using both the classifier’s intrinsic measures and permutation-based tests.

## Results
Permutation-based feature importance analysis highlighted a subset of opcodes that played a critical role in the classifier’s performance. The top 10 opcodes, based on permutation importance are shown in the figure and table below.

![download (35)](https://hackmd.io/_uploads/BJD1soAnke.png)


| op_code           | perm_importance_mean | perm_importance_std |
|-------------------|----------------------|---------------------|
| STATICCALL_gas    | 0.029730             | 0.024771            |
| STATICCALL_freq   | 0.024865             | 0.022379            |
| PUSH32_gas        | 0.021081             | 0.014744            |
| RETURN_gas        | 0.021081             | 0.018041            |
| PUSH10_freq       | 0.018378             | 0.025203            |
| MLOAD_freq        | 0.018378             | 0.029079            |
| SWAP2_freq        | 0.015676             | 0.013610            |
| SSTORE_freq       | 0.015676             | 0.011130            |
| SLOAD_gas         | 0.015135             | 0.011669            |
| DELEGATECALL_gas  | 0.015135             | 0.017314            |

> *The suffix `_gas` indicates that the feature is associated with the gas consumed by an opcode, while `_freq` indicates that the feature corresponds to the frequency at which an opcode is executed within a block.*