update defaultRuntimeConfig for v1.1.1

[etan-status]

This synchronizes defaultRuntimeConfig with v1.1.1 of the spec.

• Introduces TERMINAL_TOTAL_DIFFICULTY and TERMINAL_BLOCK_HASH.
• Sets ALTAIR_FORK_EPOCH in mainnet preset.

[arnetheduck]

There's a TODO here to not hardcode the defaultRuntimePreset constants but rather load them from the yaml file - should be fairly simple to fix this properly, can you take a look?

[etan-status]

Sure, I'm currently facing weird compile errors, only on i386, here, and meanwhile the CI somehow abandoned this PR completely. Will take a look at the YAML once that is resolved / as a followup.

/home/runner/work/nimbus-eth2/nimbus-eth2/nimbus-eth2/beacon_chain/nimbus_beacon_node.nim(1265, 5) template/generic instantiation of `closureScope` from here
23
/home/runner/work/nimbus-eth2/nimbus-eth2/nimbus-eth2/beacon_chain/nimbus_beacon_node.nim(1267, 19) template/generic instantiation of `addAsyncValidator` from here
24
/home/runner/work/nimbus-eth2/nimbus-eth2/nimbus-eth2/beacon_chain/networking/eth2_network.nim(2011, 26) template/generic instantiation of `decode` from here
25
/home/runner/work/nimbus-eth2/nimbus-eth2/nimbus-eth2/vendor/nim-serialization/serialization.nim(67, 31) Error: type mismatch: got <type SszReader, InputStreamHandle>
26
Makefile:290: recipe for target 'nimbus_beacon_node' failed
27
but expected one of: 
28
proc init[A](s: var HashSet[A]; initialSize = defaultInitialSize)
29
  first type mismatch at position: 1
30
  required type for s: var HashSet[init.A]
31
  but expression 'ReaderType`gensym478035009' is of type: type SszReader
32

33
expression: init(ReaderType`gensym478035009, stream`gensym478035008)
34

[arnetheduck]

any imports you changed, just try moving them around, for example after json_serialization

[etan-status]

CI issues were just intermittent. It resumed to run :-)

[etan-status]

The compilation problems were indeed due to some import / export shenanigans. It's weird that they only affect i386, but whatever :-)

Bundled the fix with #2960, once that one is merged, this here can be rebased and should build successfully.

[etan-status]

The YAML import I'd like to look into separately, having the defaultRuntimeConfig updated and helpers for the new types active is already good to have, especially with the general flakiness that this area seems to have.

[zah]

Let's keep the usage of the BlockHash type to the absolute minimum. The type exists only because of an inappropriate design of our package dependencies resulting in multiple competing definitions for the Ethereum types. We would like to migrate to a world where every type is defined once and used consistently everywhere. BlockHash won't exist in that world.

[etan-status]

What would be the appropriate type here? Eth2Digest?

The inspiration for this was your commit 81dc6c8

[arnetheduck]

where every type is defined once and used consistently everywhere

hm, there are some problems with that approach - mainly that you end up with massive depedency trees but also that when you change a type slightly because one consumer of the type needs something (for example a formatting of json or whatever), all dependent code has to change as well - putting up some barriers between types isn't a bad idea, often

[zah]

I would respectufully disagree that putting the said barrier is a good idea in our particular situation.

[zah]

The inspiration for this was your commit 81dc6c8

My changes are in the eth1_monitor module that needs to talk to an execution engine over JSON-RPC. Right now, types like BlockHash are the native types of nim-web3 (our json-rpc based library for consuming the Eth1 APIs). There are no good reasons for code outside the eth1_monitor module to work with these types.

[etan-status]

https://github.com/status-im/nimbus-eth2/blob/amphora-merge-interop/beacon_chain/spec/presets.nim#L73

[arnetheduck]

well, the dep tree is a practical problem - right now, to compile some simple spec tests, we also pull in libp2p which pulls in chronos and a bunch of crypto libraries that have nothing to do with the spec, merely because somewhere there's some silly type reused.

the reverse dep problem is actually more of a concern - central points of types also become central points of failure meaning a small seemingly benign change chan break many downstreams.

Anyway, this wasn't about this change in particular, rather a problem that we've been running into more frequently as the dep trees get more complex because not all projects move at the same upgrade pace.

[etan-status]

(trying whether this compiles fine without ssz change. SSZ should not be required because this field is not exchanged via RPC only via REST).

[etan-status]

Compiles fine. The CI issues were just intermittent connection issues.