Add EIP-5075: RateLimit, an outflow limiter for assets

[pr0toshi]

Limits outflows for all contract assets to a given rate in a given timeframe to limit losses from hacks

When opening a pull request to submit a new EIP, please use the suggested template: https://github.com/ethereum/EIPs/blob/master/eip-template.md

We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met:

• The PR edits only existing draft PRs.
• The build passes.
• Your GitHub username or email address is listed in the 'author' header of all affected PRs, inside .
• If matching on email address, the email address is the one publicly listed on your GitHub profile.

[eth-bot]

Hi! I'm a bot, and I wanted to automerge your PR, but couldn't because of the following issue(s):

---

(fail) eip-5075.md

classification
newEIPFile

• File with name EIPS/eip-5075.md is new and new files must be reviewed
• This PR requires review from one of [@lightclient, @axic, @SamWilsn, @Pandapip1]

[pr0toshi]

Updated license and assigned eip. Was going to at the start but the process specifically says to wait for editor. Ty for the review.

[MicahZoltu]

The filename needs updated to EIPs/eip-5075.md.

[pr0toshi]

My bad, saw needed to change just forgot when updating the rest.

[artdgn]

Cool trick to track the rate smoothly, two small concerns about the calculations:

1. Possible underflow in the reference implementation.
2. Rate limit in effect per time window can be exceeded by about 2X (in the example I thought of), perhaps worth to mention the approximate nature of the limit (or derive the worst possible deviation from it, which may be 2X but I'm not sure)

[pr0toshi]

@artdgn ah you are right does not strictly rate limit, more an av. The actual limit would be based on the previous 1h and should that be 0 yes approaches 2x for that 1h slot, though to be noted does not apply for following slots so rather than 2x, actually ends up

Net outflow limit for any time t can be seen as
ratelimit available time 0 + t * rateLimit not simply t * rateLimit, 2x for cases where the start would be 0 for the previous 1h (no activity last 1h).

So let's say that you have a time window at 100m and a rateLimit at 100 bips (so lets just say theres 1000 tokens and so 100 tokens per 100m)

Time (m)
Amount out (up to limit)
000 005 010 020 040 060 080 099 100 105 110 120...
100 005 010 010 020 020 020 014 001 005 005 010...
Delta 1h
100+.............................................099 (199 last 1h)
.......005+....................................................105 (105)

Amount out last 1h
100 105 115 125 145 165 185 199 100 105 105 110 ...

So realistically ends up as the excess possible being the free rate available at the time 0 for the window. Will update the proposal to say that. Would do mappings for amounts to stamps but the gas costs would be much higher. Though could be an alternate implementation for L2s.

Am on a phone atm so my b that may be hard to understand what was shown.

Need to check to confirm though

Note
Making the window and limit small for that window limits available rate at t0. So window 5m, limit 5 may be better, though having a spikey capacity that smoothes and makes the av rate approach target could be useful. (As at worst with a 100 bip, 1h window, would take an attacker 9h to extract vs 10) as t0 would be 1h worth, but they can only do up to the rate limit every 1h after.

[pr0toshi]

Have updated all needed details, detailed the reference implementation considerations, made the way that the limit be handled be a recommendation rather than a set value or way. Tested gas benchmarks aswell (about 12k overhead per transfer vs non rateLimited) updated the params to be more clear. Should be all good now.

[pr0toshi]

Here's my first pass. I haven't looked at the Specification, Rationale, or Backwards Compatibility sections yet.

Thankyou so much for the thorough run through. Will update the names, was just trying to keep short so that thered be a signal that it's an extension of transfer and to be used as a replacement for the most part, but will look at alternatives such as .send vs. .transfer

[github-actions]

The commit 7c7fec6 (as a parent of d2936a3) contains errors. Please inspect the Run Summary for details.

[github-actions]

The commit 16cbbfb (as a parent of 93dd9ba) contains errors. Please inspect the Run Summary for details.

[SamWilsn]

So I have to ask: why is this proposal an EIP instead of a library?

Generally speaking, EIPs are useful when you'll have multiple implementations that need to coordinate so they're all compatible. This proposal seems like you can add it to existing EIP-20 tokens without really changing the external interface.

If you strongly feel like this should be an EIP, please expand the Motivation section with your reasoning.

[github-actions]

There has been no activity on this pull request for 2 weeks. It will be closed after 3 months of inactivity. If you would like to move this PR forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[xinbenlv]

Suggested change

	created: 2022-05-05
	created: 2022-05-05
	requires: 20

Is there a dependency on ERC-20 from this EIP?

[github-actions]

There has been no activity on this pull request for 2 weeks. It will be closed after 3 months of inactivity. If you would like to move this PR forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[github-actions]

There has been no activity on this pull request for 2 weeks. It will be closed after 3 months of inactivity. If you would like to move this PR forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[github-actions]

This pull request was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.