Pith. sign in

REVIEW 6 major objections 5 minor 42 references

Demystification and Near-perfect Estimation of Minimum Gas Limit and Gas Used for Ethereum Smart Contracts

T0 review · 6 major / 5 minor · reviewed 2026-08-10 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read Ethereum's minimum gas limit can be predicted almost exactly by replaying a nearby block state.

desk verdict A genuinely useful conceptual distinction between minimum gas limit and gas used, wrapped in an empirical study whose near-perfect claim is undercut because the estimators serve as their own ground truth. read the letter →

arxiv 2501.04483 v1 pith:4K6HCMKI submitted 2025-01-08 cs.SE cs.CEcs.DCcs.ETcs.NI

Danilo Rafael de Lima Cabral , Pedro Antonino , Augusto Sampaio This is my paper · ORCID
classification cs.SEcs.CEcs.DCcs.ETcs.NI
keywords gaslimitusedminimumestimationEthereumsmartcontractsEVMblockchain
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper separates two quantities that Ethereum users and researchers have long treated as the same: the minimum gas limit a transaction needs to avoid an out-of-gas revert, and the gas it actually uses. It defines the minimum gas limit formally, shows why refunds, storage-write stipends, and gasleft-based control flow drive it apart from gas used, and confirms the gap is statistically significant on a large sample of real contract-call transactions. The paper then claims that replaying a transaction from the state after a nearby block gives a near-perfect estimate of both quantities for the same transaction at a later block: median absolute percentage error of zero for transactions without block-state-dependent opcodes, and for all sampled transactions when the block gap is at most 11. Because Ethereum adds a block roughly every 12 seconds, this means an estimate made from the current head state should stay practically exact for about two minutes. If correct, users can set gas budgets from a local node's state without waiting for inclusion, and developers should treat gas used and minimum gas limit as distinct metrics.

What carries the argument

The load-bearing object is the formal definition of minimum gas limit, $\mathrm{ming}(\sigma,T)=\min\{g \mid \Upsilon_z(\sigma,T(g))=1\}$, read operationally through two Ethereum client functions the paper models: TraceCall, which replays a transaction from a given state and returns status plus gas used, and EstimateGas, a binary search over gas budgets that calls TraceCall to find the smallest non-reverting budget. The divergence argument turns on the refund identity $g_{\text{used}}=g_{\text{cost}}-R$ and on budget constraints not reflected in execution cost, summarized by $\mathrm{ming}(\sigma,T)=g_{\text{cost}}+c-h+1$ for a gasleft-style condition $g'>c$ with completion cost $h\le c$; storage-clearing refunds and the 2300-gas SSTORE stipend are the common instances that make minimum gas limit larger than gas used. This machinery lets the paper generate concrete counterexamples and then measure both quantities from real transactions.

What would settle it

Replay the same transactions from the post-state of block $t$ to predict their execution at block $t+\Delta$, but use the actual on-chain receipt's gas used at $t+\Delta$ as ground truth for gas used, and for minimum gas limit replay from the true post-state of $t+\Delta$ with a full binary search. If the median absolute percentage error for $\Delta\le 11$ is not zero, or the error for the block-state-insensitive subset rises materially above the values reported at $\Delta=101$, the near-perfect claim would be contradicted.

Watch

Extended reading notes

Core claim

The paper establishes that the minimum gas limit for a transaction is a well-defined quantity distinct from gas used, and that both quantities can be estimated almost exactly by replaying the transaction from the state right after a nearby block. Formally, $\mathrm{ming}(\sigma,T)=\min\{g \mid \Upsilon_z(\sigma,T(g))=1\}$, while gas used is $\Upsilon_g(\sigma,T)=g_{\text{cost}}-R$; refunds, the 2300-gas storage-write stipend, and gasleft-based branches make the minimum gas limit systematically larger than gas used. On 38,174 successful contract-call transactions from a period of Ethereum Mainnet history, the paper finds statistically significant differences between the two distributions (median absolute percentage error of 6.08% even in the block-state-dependent subset), and yet replaying from the end of block $t$ gives median error 0 for both minimum gas limit and gas used at $t+\Delta$ for $\Delta\le 11$. For transactions without block-state-dependent opcodes the median error remains 0 even at $\Delta=101$; for the dynamic subset it stays small until larger gaps.

Load-bearing premise

The evaluation treats the gas values computed by replaying a transaction from the end of the previous block as the true values, and assumes that state drift between past blocks tells us how state will drift from a current block to a future one, without checking against actual on-chain transaction receipts.

Editorial extensions

If this is right

  • Users can set a transaction's gas budget by replaying it from the current head state and expect the same minimum gas limit to hold for a transaction included in the next 11 or so blocks, avoiding out-of-gas reverts and wasted fees.
  • Gas used and minimum gas limit should be reported and predicted separately; for transactions with block-state-dependent opcodes the gap can be large, so using gas-used history to set gas limits is not sound in general.
  • The two estimators can be implemented with functions already present in Ethereum execution clients, without setting up extra blockchain infrastructure.
  • Precision degrades gracefully: for transactions without block-state-dependent opcodes the median error is zero even when the state is replayed from 101 blocks back, while for dynamic transactions the mean error remains below roughly 11 percent up to that gap.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The 11-block threshold is tied to the authors' block-time assumption; on chains with faster or variable block production, the practical expiry of a replay-based estimate should be expressed in seconds rather than block count.
  • A wallet or relayer could turn this into a local budget oracle: precompute the minimum gas limit at the head state, attach it to a transaction with a short validity window, and skip per-send estimation. The paper does not build this, but its data imply it should work within 11 blocks.
  • Because the experiment defines the true value as the same client function replayed one block earlier, the near-perfect numbers partly measure self-consistency; checking predictions against actual on-chain receipts would separate genuine prediction from client determinism.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

6 major / 5 minor

Summary. The paper proposes a formal definition of the minimum gas limit for an Ethereum transaction, ming(σ,T) = min{g | Υz(σ,T(g)) = 1} (Eq. 7), and argues that this quantity is distinct from gas used. It gives qualitative examples where the two diverge, due to refunds, SSTORE gas stipends, and gasleft-dependent control flow. It then proposes that Geth's eth_estimateGas and debug_traceCall, formalized as EstimateGas and TraceCall, can serve as estimators for these two metrics. The empirical study, on first contract-call transactions of the Bellatrix fork, claims that values computed at block t are near-perfect estimates for block t+Δ when Δ ≤ 11, and that gas used and minimum gas limit differ significantly in practice.

Significance. If the empirical claims were validated against independent ground truth, the paper would make a useful conceptual and practical contribution: it clarifies a distinction that much of the gas-estimation literature conflates, provides concrete mechanisms by which the two quantities diverge, and offers a practical estimation strategy built on existing client functions. The formal definition in Eq. 7 and the explicit divergence examples in Section 3 are valuable and should be preserved. Experiment E3, interpreted as a comparison of the outputs of two client functions rather than as a measurement of true on-chain quantities, does provide evidence that the two metrics behave differently in real transactions. The paper is honest about several threats to validity, but the main empirical claim currently rests on assumptions that are not discharged, so the significance of the paper depends on the feasibility of the fixes proposed below.

major comments (6)
  1. [Section 4.1, Eq. 9] The experiment defines the 'true values' of both metrics as the outputs of EstimateGas and TraceCall at Δ = 1. This makes Experiments E1 and E2 a measure of how each function's output drifts as the evaluation state moves backward in time, not a measure of accuracy against actual on-chain values. The central claims in Section 4.5 and the Abstract require the Δ = 1 values to be correct for the actual execution of the transaction in block B. For gas used, an independent ground truth exists: the receipt gasUsed of each selected transaction, which is available for all successfully included transactions but is never used. Without such an independent reference, a stable but systematically biased estimator would appear near-perfect by construction.
  2. [Section 4.1 and Section 4.6.3] For the 33,299 transactions in Dataset D2, the paper admits that executing the zero-index transaction of block B from the final state of B−1 can differ from the real execution because of block-context opcodes such as BLOCKHASH, TIMESTAMP, and NUMBER. This means the 'true' gas-used value at Δ = 1 is not the actual gas used for a potentially large portion of the sample. The same block-context discrepancy also affects the minimum gas limit reference. The reported APE and R² values for D2 therefore conflate state drift with the systematic discrepancy between the simulated and real execution contexts. The paper should quantify how many sampled transactions actually use block-context opcodes in a way that changes execution, or exclude them from the ground-truth definition.
  3. [Section 4.1, 'Therefore, we execute the transaction in past blocks...'] The evaluation is backward-looking: it executes a transaction from states B−Δ to predict the value at B−1, and then implicitly transfers this conclusion to the forward question of predicting t+Δ from t. No stationarity or symmetry argument is given for why backward state drift over Δ blocks is representative of forward state drift. This is load-bearing for the paper's title claim of 'near-perfect estimation' of future values. For gas used, forward validation is possible in principle by comparing client simulation at the pre-block state with the actual receipt of a later included transaction; for gas limit, at minimum the direction of the state-drift assumption should be justified empirically.
  4. [Section 3.4, Algorithm 1] The paper correctly observes that EstimateGas can return a local minimum of the non-reverting gas budget intervals rather than the global minimum defined by Eq. 7; the discontinuity example returns 20021255 instead of 21275. The empirical study then assumes that 'typically' real contracts have a single non-reverting interval. This assumption is not verified on the sampled contracts. If any sampled transaction has multiple non-reverting intervals, its Δ = 1 reference value is systematically wrong, which would affect the APE and R² results in Experiment E1 and the E3 comparison. The authors should either verify the single-interval property on the dataset (for example, by probing budgets around the reported minimum) or restrict the claims to contracts where this property is known to hold.
  5. [Abstract and Section 4.5] The summary statement that the estimators are near-perfect for Δ ≤ 11 is not supported for Dataset D2. In Section 4.2, the statistical comparison between EstimateGas at Δ = 1 and Δ = 6 in D2 reports a p-value close to 0, and Section 4.5 acknowledges that for block-state-dependent transactions the precision loss is significant even from Δ = 1 to Δ = 6. Thus the near-perfect claim at Δ ≤ 11 holds, at best, for D1-style transactions without block-state-dependent opcodes. The abstract and conclusions should state this qualification explicitly.
  6. [Section 4.4, Tables 7–8] Experiment E3 compares the minimum gas limit and gas used as produced by EstimateGas and TraceCall. This is a valid comparison of the two client functions, but the paper interprets it as evidence about real transactions. For Dataset D2, both inputs to the comparison are affected by the block-context discrepancy admitted in Section 4.6.3, and for the minimum gas limit there is no independent reference. The conclusion that 'real transactions often fall into these cases where these two metrics diverge' would be stronger if the gas-used side were replaced by receipt gasUsed for the sampled transactions, or if the authors otherwise showed that the client outputs track the true on-chain values for this sample.
minor comments (5)
  1. [Section 4.1, Tables 1–6] The number of transactions reported for Δ = 1 in Tables 1–6 (e.g., 4,380 for D1) is smaller than the stated dataset sizes (4,875 for D1). Please clarify the filtering criterion that reduces the sample and whether the same sample is used across all Δ values.
  2. [Section 4.1, hypotheses] There is a typo in the null and alternative hypotheses for Experiments E1 and E2: 'for for' appears in the alternative hypotheses, and the phrase 'for all the considered values of Δs' is grammatically unclear. Please rephrase.
  3. [Section 3.2, Eq. 7] The definition of ming(σ,T) assumes the set of successful gas budgets is non-empty. For transactions that revert for every feasible gas budget, the minimum is undefined; a brief note on this case would make the definition complete.
  4. [Section 4.5] The conclusion states that EstimateGas and TraceCall are 'perfect estimators' for transactions without block-state-dependent opcodes within 2 minutes. This wording is too strong: the statistical test only shows no significant difference in the APE distributions between Δ = 1 and Δ = 6/11 for D1, not that the estimates are always exactly equal to the true values.
  5. [Section 4.2, Table 2] The discussion of the RGUM mean APE values at Δ = 11 attributes the increase to a single outlier transaction. It would be helpful to describe how this outlier was identified and whether the conclusion is robust to its removal.

Circularity Check

1 steps flagged · score 6.0 of 10

Estimation evaluation is self-referential: 'true values' are outputs of the same client functions being tested, so near-perfect APE measures self-drift rather than accuracy.

  1. self definitional [Section 4.1, Experimental Design (true-value definition; Eq. 9 APE)]
    "The values calculated by EstimateGas and TraceCall for Δ = 1 are the true values for the minimum gas limit and gas used by the input transaction, respectively. So, there are no errors for EstimateGas and TraceCall at Δ = 1, but, due to the state variation, typically there are errors for the other values of Δ and estimators."

    The evaluation fixes the reference y_i in the APE and R² metrics as the output of the very functions whose precision is being measured (EstimateGas and TraceCall), computed at Δ=1. Hence Δ=1 error is zero by construction, and Δ>1 errors only quantify how the same Geth implementation's output drifts across states B−Δ and B−1. This never compares against the formal ming(σ,T) of Eq. 7 or against actual on-chain receipts for gas used, so a systematically wrong but stable estimator would appear near-perfect. Section 3.4 demonstrates that EstimateGas can return a local minimum (20021255 instead of 21275), so the Δ=1 reference can itself be incorrect. The RQ1/RQ2 'near-perfect estimation' conclusions are therefore internal consistency checks rather than independent accuracy predictions.

full rationale

The paper's formal contribution is self-contained: Eq. 7 defines the minimum gas limit independently, and Section 3's worked examples (refunds, SSTORE stipend, gasleft conditionals) establish the distinction between minimum gas limit and gas used without relying on the empirical evaluation. There is no parameter fitting and no load-bearing self-citation chain; references to prior work are external and not used to justify the main derivation. The circularity found is confined to Experiments E1/E2: the ground truth for each metric is defined as the output of the same client function being tested at Δ=1, making the zero-error baseline tautological and the Δ>1 error an estimate of estimator self-drift rather than of accuracy against the formal quantity or the actual blockchain execution. The paper's own construct-validity threat (Section 4.6.3) concedes that the B−1 context can differ from the real B execution, and actual receipts are never used as ground truth for gas used. The extrapolation from past drift to future drift (Section 4.1) is an additional unargued assumption but is not itself circular. Consequently the central empirical claim of near-perfect future estimation is partially circular: it is supported mainly by an internal consistency measurement, while the theoretical definition and the conceptual separation of the two metrics retain independent content. Score 6 reflects this partial, load-bearing circularity in the empirical claim.

Assumptions & free parameters 0 free parameters · 5 assumptions · 0 invented entities

The central claim rests on the assumptions above rather than on fitted constants. The most important are Geth-function fidelity and backward-forward symmetry; the paper acknowledges only parts of these in its threats-to-validity section. No new physical or protocol entities are introduced.

assumptions (5)
  • domain assumption Ethereum gas accounting follows the Yellow Paper equations gcost = g0 + gexec, R = min((Tg−gcost)/5, Ar), and gused = gcost − R.
    Section 3.1 uses these equations as ground truth; the empirical claims inherit their correctness.
  • ad hoc to paper Geth 1.10.21's eth_estimateGas and debug_traceCall faithfully implement Algorithm 1 and TraceCall and agree with Eq. 7.
    Section 3.4 defines the functions by pseudocode and Section 4.1 uses their Δ=1 outputs as true values; no independent check against Eq. 7 is reported.
  • domain assumption The state after the last transaction of block B−1 equals the state before the first transaction of block B.
    Section 4.1 relies on this to make Δ=1 the reference; Sections 4.6.1 and 4.6.3 flag block-context discrepancies.
  • ad hoc to paper Backward state drift over Δ blocks is representative of forward state drift, so past-block execution answers future-prediction questions.
    Section 4.1 asserts the age-degradation measurement 'is also useful to understand how predictions for the future should behave' without a stationarity or symmetry argument.
  • ad hoc to paper For real contracts, the set of successful gas budgets is a single interval [gmin, gtop], so binary search in Algorithm 1 finds the global minimum.
    Section 3.4 states this typical case and gives a counterexample (the 'discontinuity' function) where binary search returns a local minimum, making the typical-case assumption load-bearing.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Demystification and Near-perfect Estimation of Minimum Gas Limit and Gas Used for Ethereum Smart Contracts." pith.science (2026). https://pith.science/paper/4K6HCMKI

@misc{pith2026250104483,
  author       = {Pith},
  title        = {Pith review of: Demystification and Near-perfect Estimation of Minimum Gas Limit and Gas Used for Ethereum Smart Contracts},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/4K6HCMKI}},
  note         = {Machine review of arXiv:2501.04483}
}
abstract

The Ethereum blockchain has a \emph{gas system} that associates operations with a cost in gas units. Two central concepts of this system are the \emph{gas limit} assigned by the issuer of a transaction and the \emph{gas used} by a transaction. The former is a budget that must not be exhausted before the completion of the transaction execution; otherwise, the execution fails. Therefore, it seems rather essential to determine the \emph{minimum gas limit} that ensures the execution of a transaction will not abort due to the lack of gas. Despite its practical relevance, this concept has not been properly addressed. In the literature, gas used and minimum gas limit are conflated. This paper proposes a precise notion of minimum gas limit and how it can differ from gas used by a transaction; this is also demonstrated with a quantitative study on real transactions of the Ethereum blockchain. Another significant contribution is the proposition of a fairly precise estimator for each of the two metrics. Again, the confusion between these concepts has led to the creation of estimators only for the gas used by a transaction. We demonstrate that the minimum gas limit for the state of the Ethereum blockchain (after the block) $t$ can serve as a near-perfect estimation for the execution of the transaction at block $t + \Delta$, where $\Delta \leq 11$; the same holds for estimating gas used. These precise estimators can be very valuable in helping the users predict the gas budget of transactions and developers in optimising their smart contracts; over and underestimating gas used and minimum gas limit can lead to a number of practical issues. Overall, this paper serves as an important reference for blockchain developers and users as to how the gas system really works.

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

42 extracted references · 35 canonical work pages

  1. [1]

    Ethereum: A next generation smart contract & decentralized application platform (2014)

    Buterin, V. Ethereum: A next generation smart contract & decentralized application platform (2014). URL https://ethereum.org/en/whitepaper/

    work page 2014

  2. [2]

    Bitcoin: A peer-to-peer electronic cash system (2008)

    Nakamoto, S. Bitcoin: A peer-to-peer electronic cash system (2008). URL https: //bitcoin.org/bitcoin.pdf

    work page 2008

  3. [3]

    Solidity - solidity 0.8.17 documentation (2023)

    Solidity. Solidity - solidity 0.8.17 documentation (2023). URL https://docs. soliditylang.org/en/v0.8.17/

    work page 2023

  4. [4]

    Antonopoulos, A. M. & Wood, G. Mastering Ethereum: Building Smart Contracts and DApps (O’Reilly Media, Incorporated, 2018)

    work page 2018

  5. [5]

    An evaluation of gas consumption prediction on ethereum based on transaction history summarization

    Bouraga, S. An evaluation of gas consumption prediction on ethereum based on transaction history summarization. 2020 2nd Conference on Blockchain Research and Applications for Innovative Networks and Services, BRAINS 2020 49–50 (2020)

    work page 2020

  6. [6]

    & Shaalan, K

    AlShamsi, M., Al-Emran, M. & Shaalan, K. A systematic review on blockchain adoption. Applied Sciences 12 (2022). URL https://www.mdpi.com/2076-3417/ 44 12/9/4245

    work page 2022

  7. [7]

    & Tigano, D

    Marchesi, L., Marchesi, M., Destefanis, G., Barabino, G. & Tigano, D. Design patterns for gas optimization in ethereum. Proceedings of the 2020 IEEE Interna- tional Workshop on Blockchain Oriented Software Engineering (IWBOSE) 9–15 (2020)

    work page 2020

  8. [8]

    Grech, N. et al. Madmax: Surviving out-of-gas conditions in ethereum smart contracts. Proc. ACM Program. Lang. 2 (2018). URL https://doi.org/10.1145/ 3276486

    work page 2018

Show all 42 references
  1. [9]

    & Chen, Z

    Liu, C., Gao, J., Li, Y., Wang, H. & Chen, Z. Studying gas exceptions in blockchain-based cloud applications. Journal of Cloud Computing 9, 1–25 (2020)

    2020

  2. [10]

    A., Oliva, G

    Zarir, A. A., Oliva, G. A., Jiang, Z. M. J. & Hassan, A. E. Developing cost- effective blockchain-powered applications: A case study of the gas usage of smart contract transactions in the ethereum blockchain platform 30 (2021). URL https: //doi.org/10.1145/3431726

    2021 doi

  3. [11]

    Go ethereum documentation (2023)

    Ethereum, G. Go ethereum documentation (2023). URL https://geth.ethereum. org/docs

    2023

  4. [12]

    Parity ethereum documentation (2020)

    Ethereum, P. Parity ethereum documentation (2020). URL https://github.com/ openethereum/parity-ethereum

    2020

  5. [13]

    Nethermind documentation (2023)

    Nethermind. Nethermind documentation (2023). URL https://docs.nethermind. io/nethermind/

    2023

  6. [14]

    Erigon documentation (2023)

    Erigon. Erigon documentation (2023). URL https://github.com/ledgerwatch/ erigon

    2023

  7. [15]

    Ethereum development documentation (2023)

    Ethereum. Ethereum development documentation (2023). URL https:// ethereum.org/en/developers/docs/

    2023

  8. [16]

    & Rubio, A

    Albert, E., Correas, J., Gordillo, P., Rom´ an-D ´ ıez, G. & Rubio, A. Biere, A. & Parker, D. (eds) Gasol: Gas analysis and optimization for ethereum smart con- tracts. (eds Biere, A. & Parker, D.)Tools and Algorithms for the Construction and Analysis of Systems , 118–125 (Spr...

    2020

  9. [17]

    Ma, F. et al. V-gas: Generating high gas consumption inputs to avoid out-of-gas vulnerability. ACM Trans. Internet Technol. (2022). URL https://doi.org/10. 1145/3511900. Just Accepted

    2022

  10. [18]

    Li, C., Nie, S., Cao, Y., Yu, Y. & Hu, Z. Trace-based dynamic gas estimation of loops in smart contracts. IEEE Open Journal of the Computer Society 1, 295–306 (2020). 45

    2020

  11. [19]

    Ethereum: A secure decentralised generalised transaction ledger (2014)

    Wood, G. Ethereum: A secure decentralised generalised transaction ledger (2014). URL https://ethereum.github.io/yellowpaper/paper.pdf. VERSION 6d02b75 –2024-07-29

    2014

  12. [20]

    & Gruhn, V

    Wessling, F., Ehmke, C., Hesenius, M. & Gruhn, V. How much blockchain do you need? towards a concept for building hybrid dapp architectures.2018 IEEE/ACM 1st International Workshop on Emerging Trends in Software Engineering for Blockchain (WETSEB) 44–47 (2018)

    2018

  13. [21]

    Go ethereum (2023)

    Ethereum, G. Go ethereum (2023). URL https://geth.ethereum.org

    2023

  14. [22]

    Makridakis, S. et al. The accuracy of extrapolation (time series) methods: Results of a forecasting competition. Journal of Forecasting 1, 111–153 (1982). URL https://onlinelibrary.wiley.com/doi/abs/10.1002/for.3980010202

    1982 doi

  15. [23]

    Draper, N. R. & Smith, H. Applied Regression Analysis (John Wiley & Sons, Ltd, 1998). URL https://onlinelibrary.wiley.com/doi/book/10.1002/9781118625590

    1998 doi

  16. [24]

    History and forks of ethereum (2024)

    Ethereum. History and forks of ethereum (2024). URL https://ethereum.org/ en/history/

    2024

  17. [25]

    Wohlin, C. et al. Experimentation in Software Engineering (Springer Publishing Company, Incorporated, 2012)

    2012

  18. [26]

    Kruskal, W. H. & Wallis, W. A. Use of ranks in one-criterion variance analysis. Journal of the American Statistical Association 47, 583–621 (1952). URL https: //www.tandfonline.com/doi/abs/10.1080/01621459.1952.10483441

    1952

  19. [27]

    Conover, W. J. Practical Nonparametric Statistics 3th edn (Wiley, 1999)

    1999

  20. [28]

    Table for estimating the goodness of fit of empirical distributions

    Smirnov, N. Table for estimating the goodness of fit of empirical distributions. The Annals of Mathematical Statistics 19, 279–281 (1948). URL http://www. jstor.org/stable/2236278

    1948

  21. [29]

    Installing solidity compiler - solidity 0.8.17 documentation) (2023)

    Solidity. Installing solidity compiler - solidity 0.8.17 documentation) (2023). URL https://docs.soliditylang.org/en/v0.8.17/installing-solidity.html

    2023

  22. [30]

    Marescotti, M., Blicha, M., Hyv¨ arinen, A. E. J., Asadi, S. & Sharygina, N. Mar- garia, T. & Steffen, B. (eds) Computing exact worst-case gas consumption for smart contracts. (eds Margaria, T. & Steffen, B.) Leveraging Applications of For- mal Methods, Verification and Valida...

    2018

  23. [31]

    & Sergey, I

    Albert, E., Gordillo, P., Rubio, A. & Sergey, I. Running on fumes–preventing out- of-gas vulnerabilities in ethereum smart contracts using static resource analysis (2018). URL https://arxiv.org/abs/1811.10403. 46

    2018 arXiv

  24. [32]

    Perez-Carrasco, V., Klemen, M., L´ opez-Garc ´ ıa, P., Morales, J. F. & Hermenegildo, M. V. Cost analysis of smart contracts via parametric resource analysis. Sensors Applications Symposium (2020). URL https://api. semanticscholar.org/CorpusID:229334227

    2020

  25. [33]

    & Tiezzi, F

    Bistarelli, S., Mazzante, G., Micheletti, M., Mostarda, L. & Tiezzi, F. Anal- ysis of ethereum smart contracts and opcodes. International Conference on Advanced Information Networking and Applications (2019). URL https://api. semanticscholar.org/CorpusID:85541856

    2019

  26. [34]

    Khan, M. M. A., Sarwar, H. M. A. & Awais, M. Gas consumption analysis of ethereum blockchain transactions. Concurrency and Computation: Prac- tice and Experience 34 (2021). URL https://api.semanticscholar.org/CorpusID: 243462354

    2021

  27. [35]

    Ding, Y. et al. Function-level dynamic monitoring and analysis system for smart contract. IEEE Access 8, 229161–229172 (2020). URL https://api. semanticscholar.org/CorpusID:230511556

    2020

  28. [36]

    Gas cost analysis for ethereum smart contracts (2018)

    Signer, C. Gas cost analysis for ethereum smart contracts (2018). URL https: //doi.org/10.3929/ethz-b-000312914

    2018 doi

  29. [37]

    & Chan, W

    Ashraf, I., Ma, X., Jiang, B. & Chan, W. K. Gasfuzzer: Fuzzing ethereum smart contract binaries to expose gas-oriented exception security vulnerabilities. IEEE Access 8, 99552–99564 (2020)

    2020

  30. [38]

    & Rom´ an-D ´ ıez, G

    Correas, J., Gordillo, P. & Rom´ an-D ´ ıez, G. Static profiling and optimization of ethereum smart contracts using resource analysis. IEEE Access 9, 25495–25507 (2021)

    2021

  31. [39]

    & Gruhn, V

    Severin, B., Hesenius, M., Blum, F., Hettmer, M. & Gruhn, V. Smart money wasting: Analyzing gas cost drivers of ethereum smart contracts. 2022 IEEE International Conference on Software Maintenance and Evolution (ICSME) 293–304 (2022). URL https://doi.ieeecomputersociety.org/10...

    2022

  32. [40]

    & Hobor, A

    Luu, L., Chu, D.-H., Olickel, H., Saxena, P. & Hobor, A. Making smart con- tracts smarter. Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security 254–269 (2016). URL https://doi.org/10.1145/ 2976749.2978309

    2016

  33. [41]

    A scalable method to analyze gas costs, loops and related security vulnerabilities on the ethereum virtual machine (2017)

    Kong, M. A scalable method to analyze gas costs, loops and related security vulnerabilities on the ethereum virtual machine (2017). URL https://github. com/usyd-blockchain/vandal/wiki/pubs/MKong17.pdf

    2017

  34. [42]

    & Zhang, X

    Chen, T., Li, X., Luo, X. & Zhang, X. Under-optimized smart contracts devour your money. 2017 IEEE 24th International Conference on Software 47 Analysis, Evolution and Reengineering (SANER) 442–446 (2017). URL https: //api.semanticscholar.org/CorpusID:17549597. 48

    2017

Pith tools

Reviewed August 10, 2026 · model on record in the stance chip above.