Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Precompiles and Keccak256 repricing #2666

Merged
merged 23 commits into from
Nov 9, 2020
Merged
Changes from 13 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
136 changes: 136 additions & 0 deletions EIPS/eip-2666.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,136 @@
---
eip: 2666
title: Repricing of precompiles and Keccak256 function
author: Alex Vlasov (@shamatar)
discussions-to: https://ethereum-magicians.org/t/eip2666-global-precompiles-repricing-and-many-more-discussion-thread/4332
status: Draft
type: Standards Track
category: Core
created: 2020-05-22
requires: 1352, 2046, 2565
---

## Simple Summary
This EIP tries to fix the problems with Ethereum precompiles and built-in EVM function:
- EIP-2046 changes a `STATICCALL` cost to precompile and it may be necessary to adjust costs of some precompiles that have taken old large cost (`700` gas) into account
- Some precompiles are overpriced and their pricing formulas to not reflect the structure of underlying function
- Keccak256 built-in function in EVM has pricing that does not reflect underlying hash function structure
- Better specify behavior of how gas handled if the precompile call fails (DDoS handling behavior)
shamatar marked this conversation as resolved.
Show resolved Hide resolved

## Abstract
Costs of many precompiles and built-in functions are invalid at the current state of the clients. This EIP contains a list of changes to the pricing formulas to better reflect underlying computations' structure.
shamatar marked this conversation as resolved.
Show resolved Hide resolved

## Motivation
Motivation is simple: make pricing formulas accurately reflect resources (CPU time) requires to actually perform the called computations.
shamatar marked this conversation as resolved.
Show resolved Hide resolved

## Specification

This EIP proposes the following changes:
- Small running time to perform gas estimation for precompile call is absorbed into the precompile cost itself
- Precompiles are repricied as:
- `SHA256` precompile (address `0x02`) was priced as `60` gas plus `12` gas per `32` bytes of input. Now it should be priced as `10 + ((len(input) + 8)/64 + 1) * 9`
- RIPEMD precompile (address `0x03`) was priced as `600` gas plus `120` gas per `32` bytes of input. Now it should be priced as `6 + ((len(input) + 8)/64 + 1) * 12`
- `BNADD` precompile (address `0x06`) should be repriced from `150` gas to `350` gas
- `BNMUL` precompile (address `0x07`) should be repriced from `6000` gas to `6300` gas
- Keccak256 built-in function was priced as `30` gas plus `6` gas per `32` bytes of the input. Now it should be priced as `13 + (len(input)/136 + 1)*15`

This EIP ideally requires that `MODEXP` repricing is [implemented](https://eips.ethereum.org/EIPS/eip-2565) to also accurately reflect that there is implicit compensation for an old `STATICCALL` cost (pre-2046).

### Benchmarks on the most popular clients

Necessary benchmarks for EIP 2666 were provided by the clients and raw form is assembled in [here](https://docs.google.com/spreadsheets/d/1aCQnk7prrp3Mbcf011BE5zZnkbc3Iw7QAixn6mLbKS0/edit?usp=sharing)


Short summary:
- BNADD

| |   | Gas |
|---| ---|---|
Geth |   | 350
OE |   | 225
Besu |   | 165
Nethermind |   | 120

BNADD cost will need to be adjusted when EIP 2046 is accepted

- BNMUL

| |   | Gas |
|---| ---|---|
Geth |   | 3000
OE |   | 6250
Besu |   | 19109
Nethermind |   | 5250

Besu result is surprising and is not taken into account. Only little repricing will be necessary when EIP 2046 is accepted

- SHA256 precompile

Currently it's 60 gas + 12 gas per 32 byte word. Proposed formula is `A * ((len(input) + 8) / 64 + 1) + B`, with coefficients below

| | | A | B |
|---|---|---|---|
| Geth | | 5 | 3 |
| OE | | 9 | 4 |
| Besu | | 5 | 10 |
| Nethermind | | 10 | 5 |

EIP 2666 proposes `A = 9`, `B = 10`. There are no large one-off costs in this precompile, so it's EIP 2046 - safe.

- RIPEMD precompile

Currently it's 600 gas + 120 gas per 32 byte word. Proposed formula is `A * ((len(input) + 8) / 64 + 1) + B`, with coefficients below

| | | A | B |
|---|---|---|---|
| Geth | | 12 | 6 |
| OE | | 8 | 2 |
| Besu | | 29 | 16 |
| Nethermind | | 10 | 6 |

EIP 2666 proposes `A = 12`, `B = 6`. There are no large one-off costs in this precompile, so it's EIP 2046 - safe. Besu expects to have performance improvements by the end of the year.

- Keccak256 performance

Currently it's 30 gas + 6 gas per 32 byte word. Proposed formula is `A * (len(input) / 136 + 1) + B`, with coefficients below

| | | A | B |
|---|---|---|---|
| Geth | | 13 | 13 |
| OE | | 15 | 2 |
| Besu | | 19 | 28 |
| Nethermind | | 16 | 3 |

EIP 2666 proposes `A = 15`, `B = 13`. There are no large one-off costs in this precompile, so it's EIP 2046 - safe. Besu expects to have performance improvements by the end of the year.

### Inclusion plan

EIP 2046 can not be accepted without at least part of the repricings from this EIP (namely for `BNADD` and `BNMUL`). Even though work necessary to activate this EIP is very small (adjust few constants), one can also consider two step plan that can be implemented as the following:
- Include EIP 2046 and `BNADD`/`BNMUL` repricings
- Include repricings for `SHA256`, `RIPEMD` and `Keccak256`
shamatar marked this conversation as resolved.
Show resolved Hide resolved

## Rationale
Cost of functions being executed must accurately reflect real CPU time spent on computations, so benchmarking was performed for current precompiles and Keccak256 function to measure running time versus input parameters.

## Backwards Compatibility
Precompile repricings has happened in a past and can be considered standard procedure. Gas costs of many contracts is expected to reduce that may break re-entrancy protection measures based on fixed gas costs. In any case, such protection should have never been considered good and final.

## Test Cases

There are no explicit test cases.
shamatar marked this conversation as resolved.
Show resolved Hide resolved

## Implementation

Reference material with raw data can be found [here](https://docs.google.com/spreadsheets/d/1aCQnk7prrp3Mbcf011BE5zZnkbc3Iw7QAixn6mLbKS0/edit?usp=sharing).

There is a repository available with inputs for benchmarking and precompiles testing [here](https://github.com/shamatar/bench_precompiles).

Raw Besu [benchmarks](https://gist.github.com/shemnon/0ddba91be501fa23291bdec9107fe99a).

shamatar marked this conversation as resolved.
Show resolved Hide resolved

## Security Considerations

As described in backward compatibility section in some cases reduction of cost may allow e.g. re-entrancy that was not expected before, but we think that re-entrancy protection based on fixed gas costs is anyway flawed design decision.

## Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).