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

Net gas metering for SSTORE with a reentrancy protection #1706

Merged
merged 1 commit into from
Jan 17, 2019
Merged
Changes from all 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
71 changes: 71 additions & 0 deletions EIPS/eip-1706.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,71 @@
---
eip: 1706
title: Disable SSTORE with gasleft lower than call stipend
author: Alex Forshtat (alex@tabookey.com), Yoav Weiss (yoav@tabookey.com)
discussions-to: https://github.com/alex-forshtat-tbk/EIPs/issues/1
status: Draft
type: Standards Track (Core, Networking, Interface, ERC)
category (*only required for Standard Track): Core
created: 2019-01-15
requires (*optional): 1283
---

<!--You can leave these HTML comments in your merged EIP and delete the visible duplicate text guides, they will not appear and may be helpful to refer to if you edit it again. This is the suggested template for new EIPs. Note that an EIP number will be assigned by an editor. When opening a pull request to submit your EIP, please use an abbreviated title in the filename, `eip-draft_title_abbrev.md`. The title should be 44 characters or less.-->

## Simple Summary
<!--"If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the EIP.-->
The proposal that had been accepted changes security properties of a large portion of an existing contract code base that may be infeasible to update and validate. This proposal will make the old assumptions hold even after a network upgrade.

## Abstract
<!--A short (~200 word) description of the technical issue being addressed.-->
[EIP-1283](https://eips.ethereum.org/EIPS/eip-1283) significantly lowers the gas costs of writing to contract's storage. This created a danger of a new kind of reentrancy attacks on existing contracts as Solidity by default grants a 'stipend' of 2300 gas to simple transfer calls.
This danger is easily mitigated if SSTORE is not allowed in low gasleft state, without breaking the backward compatibility and the original intention of this EIP.

## Motivation
<!--The motivation is critical for EIPs that want to change the Ethereum protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the EIP solves. EIP submissions without sufficient motivation may be rejected outright.-->

An attack that is described in [this article](https://medium.com/chainsecurity/constantinople-enables-new-reentrancy-attack-ace4088297d9).
Explicitly specifying the call stipend as an invariant will have a positive effect on Ethereum protocol security:
https://www.reddit.com/r/ethereum/comments/agdqsm/security_alert_ethereum_constantinople/ee5uvjt

## Specification
<!--The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (go-ethereum, parity, cpp-ethereum, ethereumj, ethereumjs, and [others](https://github.com/ethereum/wiki/wiki/Clients)).-->

Add the following condition to to the SSTORE opcode gas cost calculation:

* If *gasleft* is less than or equal to 2300, fail the current call frame
with 'out of gas' exception.

## Rationale
<!--The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.-->
In order to keep in place the implicit reentrancy protection of existing contracts, transactions should not be allowed to modify state if the remaining gas is lower then the 2300 stipend given to 'transfer'/'send' in Solidity.
These are other proposed remediations and objections to implementing them:

* Drop EIP-1283 and abstain from modifying SSTORE cost
* EIP-1283 is an important update
* It was accepted and implemented on test networks and in clients.
* Add a new call context that permits LOG opcodes but not changes to state.
* Adds another call type beyond existing regular/staticcall
* Raise the cost of SSTORE to dirty slots to >=2300 gas
* Makes net gas metering much less useful.
* Reduce the gas stipend
* Makes the stipend almost useless.
* Increase the cost of writes to dirty slots back to 5000 gas, but add 4800 gas to the refund counter
* Still doesn’t make the invariant explicit.
* Requires callers to supply more gas, just to have it refunded
* Add contract metadata specifying per-contract EVM version, and only apply SSTORE changes to contracts deployed with the new version.


## Backwards Compatibility
<!--All EIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The EIP must explain how the author proposes to deal with these incompatibilities. EIP submissions without a sufficient backwards compatibility treatise may be rejected outright.-->
Performing SSTORE has never been possible with less than 5000 gas, so it does not introduce incompatibility to the Ethereum mainnet. Gas estimation should account for this requirement.

## Test Cases
<!--Test cases for an implementation are mandatory for EIPs that are affecting consensus changes. Other EIPs can choose to include links to test cases if applicable.-->
Test cases for an implementation are mandatory for EIPs that are affecting consensus changes. Other EIPs can choose to include links to test cases if applicable.
TODO
## Implementation
<!--The implementations must be completed before any EIP is given status "Final", but it need not be completed before the EIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details.-->
TODO
## Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).