Bound history size #4444
Bound history size #4444
Conversation
|
All tests passed; auto-merging... |
| | - | - | - | | ||
| | `HISTORY_PRUNE_EPOCHS` | 82125 | A year in beacon chain epochs | | ||
|
|
||
| Clients MUST NOT serve blocks/states/receipts that are older than `HISTORY_PRUNE_EPOCHS` epochs on the p2p network. |
There was a problem hiding this comment.
Not everyone will agree on what time it is, should we have a bit of a no-mans-land between the time clients are expected to stop requesting ancient data and when clients are expected to stop providing ancient data? This could be minutes/hours/days, just enough to deal with time synchronization issues.
Presumably, under such a regime any peer that requests data older than the longer of the two SHOULD be kicked. Meanwhile, clients SHOULD be programmed to never ask for anything older than the shorter of the two.
There was a problem hiding this comment.
So I can/should locally prune after these epochs, and thus I can be in a situation where our clocks have a disparity (within reason) and you make what you think is an honest request that I do not have. Are you suggesting in such a situation that although I cannot respond to the request, I should not consider your request as nefarious? Whereas if you are outside of the window, I can consider this as "bad" behavior and descore/kick you?
under such a regime any peer that requests data older than the longer of the two SHOULD be kicked
I prefer MAY be downscored and/or kicked.
There was a problem hiding this comment.
Not everyone will agree on what time it is, should we have a bit of a no-mans-land between the time clients are expected to stop requesting ancient data and when clients are expected to stop providing ancient data? This could be minutes/hours/days, just enough to deal with time synchronization issues.
Presumably, under such a regime any peer that requests data older than the longer of the two SHOULD be kicked. Meanwhile, clients SHOULD be programmed to never ask for anything older than the shorter of the two.
@MicahZoltu In my country, MasterCard and Visa while not blockchain related are required to keep past history of the last 10 years for law enforcement and they use a higher transaction throughout.
| ## Specification | ||
|
|
||
| | Parameter | Value | Description | | ||
| | - | - | - | | ||
| | `HISTORY_PRUNE_EPOCHS` | 82125 | A year in beacon chain epochs | | ||
|
|
||
| Clients MUST NOT serve blocks/states/receipts that are older than `HISTORY_PRUNE_EPOCHS` epochs on the p2p network. | ||
|
|
||
| Clients MAY locally prune block/state/receipt history that is older than `HISTORY_PRUNE_EPOCHS` epochs. |
There was a problem hiding this comment.
Specification should indicate what behavior should occur if a peer asks for data that is too old (which is why I think this should be a Networking spec).
There was a problem hiding this comment.
Why should anything specific occur? There are a small number of clients, we should work together to ensure that they follow the behavior of the EIP.
There was a problem hiding this comment.
It's been argued that requesting and serving data beyond the limit should be explicitly incorrect. In such a case, you'd need to have devp2p return errors on such requests
|
This should be ready to be reviewed again. It would be great to move any outstanding questions regarding the actual EIP to the discussion thread: https://ethereum-magicians.org/t/eip-4444-bound-historical-data-in-execution-clients/7450 |
* add draft of eip to bound history size * a few updates * add discussion url * change category to networking * fix malformed handle
Clients must stop serving historical blocks/receipts that are older than a year on the p2p layer. Clients may prune such historical data.