Lazy crypto [alt design #1369]

[mratsim]

This is a reboot of #457 which was abandoned because of noSideEffect limitations in Nim 0.20 and the old nim-blscurve (status-im/nim-blscurve#27).

This is an alternative to #1369 (comment).

Unfortunately there is no free lunch and this has tradeoffs somewhat similar to copy-on-write schemes:

• Mutability is hidden and done through an unsafe pointer (though can only happen once)

Also with regards to serialization and compared to #1369 it's stateless. This is the main difference between both PR:

Stateful requires yet another table, increasing memory usage and complicating threading in the future. It also requires more hashing, indirection and copy to manipulate both cached and non-cached BLS objects.

Stateless (this PR) tricks the compiler with pointers but uses significantly less memory and has no indirection.
It will have to deserialize objects that are received multiple times in different contexts (for example a public key from the network which may be received multiple times).

I.e. in terms of perf, the main difference is deserializing a public key vs looking it up in a table.
The full impact depends on how often we receive the same object in an unrelated context

Both should solve the loading latency from BeaconChainDB.

[stefantalpalaru]

Genuine runtime error here: https://ci.status.im/blue/rest/organizations/jenkins/pipelines/nimbus/pipelines/nim-beacon-chain/pipelines/multibranch/branches/lazy-crypto/runs/1/nodes/92/log/?start=0

[tersec]

As a first impression, it's mechanically messier but isolates it better, while being conceptually cleaner. Avoiding a constantly, even if slowly, growing memory usage source and point of indirection does have value.

I'd be concerned somewhat about the extent to which it's dependent on specifics of old case objects, which I'm fine with in general but also upon which it seems worth considering increasing dependence. Not a major risk, as we have an existence proof of at least one other way to achieve similar ends. Furthermore, as I recall, there might be other reasons we already depend on -d:oldCaseObjects, in which case, this would be a marginal difference only.

Also, precisely because it does fool the compiler with unsafeAddr and somewhat (for a good cause) undermine its effects analysis, it creates some ongoing risk wherein if it introduces certain types of issues, they could prove trickier to track down. Still, it's a small kernel of code, so probably fine.

Finally, it's not clear to me how/if it avoids the deposits issue where searching for a pubkey in beaconstate might get confused about which kind of ValidatorPubKey the searched-for key is and which is in BeaconState.validators, or that it's especially careful to avoid those inconsistencies to begin with. I'm probably just not understanding that though, and regardless, it's not a fundamental part of either this or 1369.

That said, I do, overall, prefer this design abstractly, as an interface for non spec/crypto parts of nim-beacon-chain to use.