eth/catalyst: evict old payloads, type PayloadID

[protolambda]

Changes:

• Remove PayloadResponse: dead code since last spec update, ForkchoiceUpdatedV1 returns the ID with status instead
• Evict prepared payloads with a LRU of size 10. Preparing payloads with 10 different inputs in parallel, and reverting to the inputs of the first request should be very rare. This prevents the node from running out of memory over time when producing blocks. Update: LRU cache has been replaced with one specific for this functionality.
• Type the PayloadID: cleans up API functions, no more hash / uint64 / hex conversions. And strict payload ID type parsing (previously > 8 bytes IDs were allowed)
• Remove InvalidPayloadID: non-standard error
• Changing to the thread-safe LRU prevents the ForkchoiceUpdatedV1 from panicking on concurrent map writes to the previous map

cc @MariusVanDerWijden

edit: updated, forgot goimports

[MariusVanDerWijden]

LGTM, I've added a commit on top that enables some more tracing

[protolambda]

Amended commit to fix logging inconsistency: s/payloadid/payloadID/g

[MariusVanDerWijden]

@protolambda I've added another test on top

[MariusVanDerWijden]

We discussed this PR in triage a bit and came to the conclusion that a cache is not a great structure for this.
It would be best to use a map and write our own eviction rules from the map, since we can be sure that they fit our use case then.
Do you want to do that @protolambda? If not, I can also take over

[protolambda]

@MariusVanDerWijden Can you define the desired eviction rules? Simplicity is nice too. It's just temporary memory of the latest few payloads that produce/get functions need to exchange. I can help if you can describe what you need in more detail.

[karalabe]

This change is no really a good one. The role of a "cache" is to keep some recent data available-ish, but it's at the sole discretion of the implementation as to how long and when to evict. Whilst it might seem like not a bad idea at first to use a cache to store recent payloads, losing control of storage determinism can make thing in the future a lot harder to debug.

E.g. Certain caches have limits on the maximum size an item can have and will simply refuse to store something larger. In this context it could happen that if the payload exceeds a certain size, the cache would not store it anymore, making it unmineable. If all nodes would create a similarly large block they can't store, we could end u[ with a stalled network. Now I don't know if this particular cache behaves like that or not - or what the limits are - but this is exactly why a cache should not be used, because it's a disk access "optimization", not a storage data structure.

[protolambda]

Agreed about a cache not being the right fit here after a second look. But previously it would just keep growing indefinitely, and I discussed this change and eviction number with Marius before implementing it. Least-recently-used as eviction strategy + a fixed size limit seemed reasonable enough. Can you describe what you prefer instead?

[karalabe]

Depends how much work you want to put in and what the size of the set will be.

If we take the current cap of 10, then you could use a simple slice and just shift the contents on every insert and do a linear search on every retrieval. We're expected do do these ops rarely when it's our turn to sign, and even then once to create the payload and once to retrieve it within a 14 second time fame. A 10 item iteration doesn't matter in that scope.

If we were to make the set larger, the best solution would probably be a map as it was originally and an eviction order queue. That could be a channel or a circular queue (we have one in the code). But I don't see a reason to complicate it like that.

My 2c, unless there's a reason no to, just go with slice shifting / iteration.

[karalabe]

Pls delete this, it's dead code. Otherwise LGTM

[karalabe]

SGTM, will merge on green