EIP-2583: Penalty for account trie misses #2583

holiman · 2020-04-03T11:08:15Z

This EIP implements a penalty-scheme for operations which are heavy on the trie. The scheme is designed to be as little disruptive as possible to existing contracts.

axic · 2020-04-03T11:29:30Z

EIPS/eip-draft-trie-penalty.md

+- A `penalty` of `3000`would lower the number to ~`2700` lookups, `20%` of the original. 
+- A `penalty` of `4000`would lower the number to ~`2100` lookups, `15%` of the original. 
+
+There exists a roofing function for the `penalty`. Since the `penalty` is deducted from `gas`, that means that a malicious contract can always invoke a malicious relay to perform the trie lookup. 


Maybe it is worth considering the idea which was brought up as part of "Stateless Summit". Have a separate counter, this time for the entire transaction frame, for the penalty counting. This same counter could be used for witness size counting.

Wouldn't it eliminate this attack vector?

livnev · 2020-04-04T17:42:21Z

EIPS/eip-draft-trie-penalty.md

+
+1. Storage tries are typically small, and there's a high cost to populate a storage trie with sufficient density for it to be in the same league as the account trie. 
+2. If an attacker wants to use an existing large storage trie, e.g. some popular token, he would typically have to make a `CALL` to cause a lookup in that token -- something like `token.balanceOf(<inexistant-address>)`. 
+   That adds quite a lot of extra gas-impediments, as each `CALL` is another `700` gas, plus gas for arguments to the `CALL`. 


Is this dependent on the assumption that there are no popular contracts (i.e. ones with an existing large storage trie) with a method that reads a large number of (caller-determined) storage entries? If so, it would be nice to state this assumption explicitly here. (e.g. a theoretical popular token contract with a sumBalanceOf(address[]) method or something like that)

Also if I understood you correctly, I would remove "plus gas for arguments to the CALL", since the CALL opcode doesn't charge gas for input data and presumably the DoS-attacker would generate the cache-miss arguments on-chain rather than passing them as tx data. The point about the minimum of 700 gas per cache-miss is still valid though.

Well, I guess it could be several different ways to do this. However, it's much eaiser to get a 'random' number as a single stack-op, (e.g. gas), than if you have to pre-fill a memory segment with 'random' data and pass it to another method. Every argument you send is another 32 byte memory expanded on the caller-side.

One could experiment more in-depth about exactly what the costs would be, but I don't think it would be marginal.

Also if I understood you correctly, I would remove "plus gas for arguments to the CALL", since the CALL opcode doesn't charge gas for input data

You are correct that it doesn't, however, I was referring to the fact that you need to get your input first to stack, then load into memory. If you do it over and over (as opposed to a one-off multi-parameter thing), then you need to flip some bits between calls, to not hit the same thing over and over again.

EIPS/eip-draft-trie-penalty.md

Co-Authored-By: Alex Beregszaszi <alex@rtfs.hu>

axic · 2020-04-21T10:03:25Z

Spelling typos:

EIPS/eip-2583.md:15: non-existant  ==> non-existent
EIPS/eip-2583.md:28: non-existant  ==> non-existent
EIPS/eip-2583.md:70: inexistant  ==> inexistent
EIPS/eip-2583.md:71: inexistant  ==> inexistent
EIPS/eip-2583.md:249: non-existant  ==> non-existent

axic · 2020-08-28T20:12:21Z

@holiman hope you don't mind the spelling fix. I think this draft should be merged for the record and to have a good reference for discussion. Even if this version may not be pursued further.

MicahZoltu · 2020-08-29T04:17:25Z

EIPS/eip-2583.md

+
+## Simple Summary
+
+This EIP propose to introduce a gas penalty for opcodes which access the account for trie non-existent accounts.


EIPs don't propose, they assert. One may propose an EIP be adopted (in some other venue than the EIP document), but the EIP itself is an assertion of some change.

MicahZoltu · 2020-08-29T04:18:27Z

EIPS/eip-2583.md

+This EIP proposes to add a gas penalty for accesses to the account trie, where the address being looked up does not exist. Non-existing accounts can be used in 
+DoS attacks, since they bypass cache mechanisms, thus creating a large discrepancy between 'normal' mode of execution and 'worst-case' execution of an opcode. 


A lot of this feels like motivation, not abstract. Abstract should be a terse human-friendly version of the specification section.

MicahZoltu · 2020-08-29T04:19:39Z

EIPS/eip-2583.md

+
+## Specification
+
+We define the constant `penalty` as `TBD` (suggested `2000` gas).


Suggested change

We define the constant `penalty` as `TBD` (suggested `2000` gas).

We define the constant `penalty` as `2000`.

Recommended during Draft (not required until Last Call): EIPs are assertions, put the number you want in and you can always change it later (while it is in draft). Alternatively, if you don't want a sticky default just put in TBD and discuss 2000 in the discussion-to link.

MicahZoltu · 2020-08-29T04:20:21Z

EIPS/eip-2583.md

+
+

Nitpick: should be 1 newline or 0 (depending on personal style, have seen both used in this repository).

MicahZoltu · 2020-08-29T04:22:27Z

EIPS/eip-2583.md

+A transaction with `10M` gas can today cause ~`14K` trie lookups.
+
+- A `penalty` of `1000`would lower the number to ~`5800` lookups, `41%` of the original.
+- A `penalty` of `2000`would lower the number to ~`3700` lookups, `26%` of the original.
+- A `penalty` of `3000`would lower the number to ~`2700` lookups, `20%` of the original. 
+- A `penalty` of `4000`would lower the number to ~`2100` lookups, `15%` of the original. 
+
+There exists a roofing function for the `penalty`. Since the `penalty` is deducted from `gas`, that means that a malicious contract can always invoke a malicious relay to perform the trie lookup. Let's refer to this as the 'shielded relay' attack. 
+
+In such a scenario, the `malicious` would spend `~750` gas each call to `relay`, and would need to provide the `relay` with at least `700` gas to do a trie access.
+
+Thus, the effective `cost` would be on the order of `1500`. It can thus be argued that `penalty` above `~800` would not achieve better protection against state-inexistence attacks. 


This should be in the Rationale section. The rationale is where you discuss why you chose the constants you chose. The specification section should merely assert that the constant is X and it is applied here, here, and here.

MicahZoltu · 2020-08-29T04:24:53Z

EIPS/eip-2583.md

+
+| Opcode | Affected | Comment | 
+| -----  | ---------| ----------|
+| BALANCE| Yes      | `balance(inexistent_addr)` would incur `penalty`|


Is inexistent a word? I thought only nonexistent was? Spell checker says no, Bing thinks I want to translate from French when I type it in, but there are a couple online dictionaries that have an entry for inexistent.

Recommend switching to nonexistent unless there is a strong belief that this is in fact a word and means something different than nonexistent.

MicahZoltu · 2020-08-29T04:26:54Z

EIPS/eip-2583.md

+## Alternative variants
+
+### Alt 1: Insta-refunds
+
+Bump all trie accesses with `penalty`. `EXTCODEHASH` becomes `2700` instead of `700`. 
+- If a trie access hit an existing item, immediately refund penalty (`2K` )
+
+Upside:
+
+- This eliminates the 'shielded relay' attack
+
+Downside: 
+
+- This increases the up-front cost of many ops (CALL/EXTCODEHASH/EXTCODESIZE/STATICCALL/EXTCODESIZE etc)
+  - Which may break many contracts. 
+
+### Alt 2: Parent bail
+
+Use `penalty` as described, but if a child context goes OOG on the `penalty`, then the remainder is subtracted from the 
+parent context (recursively).
+
+Upside:
+
+- This eliminates the 'shielded relay' attack
+
+Downside: 
+
+- This breaks the current invariant that a child context is limited by whatever `gas` was allocated for it. 
+  - However, the invariant is not _totally_ thrown out, the new invariant becomes that it is limited to `gas + penalty`.
+- This can be seen as 'messy' -- since only _some_ types of OOG (penalties) becomes passed up the call chain, but not others, e.g. OOG due to trying
+  to allocate too much memory. There is a distinction, however: 
+  - Gas-costs which arise due to not-yet-consumed resources do not get passed to parent. For example: a huge allocation is not actually performed if there is insufficient gas. 
+  - Whereas gas-costs which arise due to already-consumed resources _do_ get passed to parent; in this case the penalty is paid post-facto for a trie iteration. 


All of this should either move to discussion-to link or be restructured to fit into the Rationale section (the section for "why did we do X instead of Y"). EIPs are technical documents that define a specification, they aren't meant to be discussion platforms or a log of discussions on a topic.

MicahZoltu · 2020-08-29T04:30:43Z

I think this draft should be merged for the record and to have a good reference for discussion. Even if this version may not be pursued further.

I'm generally not a fan of merging EIPs that the author is going to immediately abandon, however I don't think we have a policy against that at the moment so I'll move forward with merging this and just say that I would prefer we don't do that in the future.

axic · 2020-08-29T12:11:09Z

This was discussed on ACD a few times and I think an upcoming EIP may or may not deprecate it. For properly referencing it makes sense, but I'm not 100% sure what is the best option.

lightclient · 2020-08-29T20:02:31Z

It would be interesting if we had a "draft track" akin to the RFC "Internet draft". In that case we could be much more lenient on the draft track and then be more strict when it comes time for an EIP. That might also help people avoid grabbing EIP numbers to grandstand an issue.

holiman · 2020-08-29T21:17:13Z

I don't mind polishing this eip up a bit, even if it's not going to be pursued. Thanks for all comments!I'll submit some changes in a couple of days

* eip x: draft trie penalty * Update EIPS/eip-draft-trie-penalty.md Co-Authored-By: Alex Beregszaszi <alex@rtfs.hu> * EIP-2583: rename file * 2583: discussion-to + two alternative variants * 2583: formatting * Fix wording: *existant -> *existent Co-authored-by: Alex Beregszaszi <alex@rtfs.hu>

eip x: draft trie penalty

db1e389

holiman mentioned this pull request Apr 3, 2020

Ethereum Core Devs Meeting 84 Agenda ethereum/pm#162

Closed

axic reviewed Apr 3, 2020

View reviewed changes

livnev reviewed Apr 4, 2020

View reviewed changes

axic reviewed Apr 7, 2020

View reviewed changes

EIPS/eip-draft-trie-penalty.md Outdated Show resolved Hide resolved

holiman and others added 4 commits April 10, 2020 15:21

Update EIPS/eip-draft-trie-penalty.md

fa1e06a

Co-Authored-By: Alex Beregszaszi <alex@rtfs.hu>

EIP-2583: rename file

40876ed

2583: discussion-to + two alternative variants

7725776

2583: formatting

d802b3f

holiman mentioned this pull request Apr 17, 2020

Ethereum Core Devs Meeting 85 Agenda ethereum/pm#164

Closed

Souptacular mentioned this pull request Apr 17, 2020

Ethereum Core Devs Meeting 86 Agenda ethereum/pm#165

Closed

axic changed the title ~~eip x: draft trie penalty~~ EIP-2583: Penalty for account trie misses Apr 21, 2020

axic added the type: Core label Apr 21, 2020

axic added 2 commits August 28, 2020 21:07

Merge remote-tracking branch 'ethereum/master' into HEAD

c01f508

Fix wording: *existant -> *existent

605e2ef

axic approved these changes Aug 28, 2020

View reviewed changes

MicahZoltu reviewed Aug 29, 2020

View reviewed changes

MicahZoltu approved these changes Aug 29, 2020

View reviewed changes

MicahZoltu merged commit 93072ce into ethereum:master Aug 29, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

EIP-2583: Penalty for account trie misses #2583

EIP-2583: Penalty for account trie misses #2583

holiman commented Apr 3, 2020

axic Apr 3, 2020

livnev Apr 4, 2020

holiman Apr 7, 2020

axic commented Apr 21, 2020

axic commented Aug 28, 2020

MicahZoltu Aug 29, 2020 •

edited

Loading

MicahZoltu Aug 29, 2020

MicahZoltu Aug 29, 2020

MicahZoltu Aug 29, 2020

MicahZoltu Aug 29, 2020

MicahZoltu Aug 29, 2020

MicahZoltu Aug 29, 2020

MicahZoltu commented Aug 29, 2020

axic commented Aug 29, 2020

lightclient commented Aug 29, 2020 •

edited

Loading

holiman commented Aug 29, 2020 via email


		## Simple Summary

		This EIP propose to introduce a gas penalty for opcodes which access the account for trie non-existent accounts.

		This EIP proposes to add a gas penalty for accesses to the account trie, where the address being looked up does not exist. Non-existing accounts can be used in
		DoS attacks, since they bypass cache mechanisms, thus creating a large discrepancy between 'normal' mode of execution and 'worst-case' execution of an opcode.


		## Specification

		We define the constant `penalty` as `TBD` (suggested `2000` gas).

	We define the constant `penalty` as `TBD` (suggested `2000` gas).
	We define the constant `penalty` as `2000`.

EIP-2583: Penalty for account trie misses #2583

EIP-2583: Penalty for account trie misses #2583

Conversation

holiman commented Apr 3, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

axic commented Apr 21, 2020

axic commented Aug 28, 2020

MicahZoltu Aug 29, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MicahZoltu commented Aug 29, 2020

axic commented Aug 29, 2020

lightclient commented Aug 29, 2020 • edited Loading

holiman commented Aug 29, 2020 via email

MicahZoltu Aug 29, 2020 •

edited

Loading

lightclient commented Aug 29, 2020 •

edited

Loading