Alex Vlasov

In general, I'm thinking about three-four levels of de-duplication: - test parts level, where a part is a top-level container (BeaconState, SignedBeaconBlock, Attestation, etc) - in the case of fork...

I've generated a version fork choice tests for [v012x](https://github.com/ethereum/eth2.0-specs/tree/v012x) branch and put them [here](https://github.com/harmony-dev/eth2.0-spec-tests/tree/fork_choice_integration_tests_v012x/tests/minimal/phase0/fork_choice/integration_tests). Code to generate and to run the tests against `pyspec phase0` are put into the [branch](https://github.com/ericsson49/eth2.0-specs/tree/v012x_fork_choice_tests/tests/generators/fork_choice)....

I've created a version of fork choice test format, which allows optional checks, e.g.: ``` block_in_store: value: '0x654dd99167c3b155924aad2a19086a70f89daa2b0cb86effb07a3e0488c5669c' optional: false ``` instead of just ``` block_in_store: '0x654dd99167c3b155924aad2a19086a70f89daa2b0cb86effb07a3e0488c5669c' ``` Tests are...

I've updated tests to match [v0.12.2](https://github.com/ethereum/eth2.0-specs/tree/v0.12.2). Tests are [here](https://github.com/txrx-research/eth2.0-spec-tests/tree/fork_choice_integration_tests_v012_2/tests/minimal/phase0/fork_choice/integration_tests) and [here (optional checks)](https://github.com/txrx-research/eth2.0-spec-tests/tree/fork_choice_integration_tests_v012_2_optional_checks/tests/minimal/phase0/fork_choice/integration_tests). Code to generate the tests is [here](https://github.com/ericsson49/eth2.0-specs/tree/v012_2_fork_choice_tests/tests/generators/fork_choice) and [here (optional checks)](https://github.com/ericsson49/eth2.0-specs/tree/v012_2_fork_choice_tests_optional_checks/tests/generators/fork_choice).

> Thanks! This is great work. Are we planning to merge these into the official eth2.0-spec-tests repo? Thanks! They were supposed to be merged, but I do not know current...

As a part of my research I plan to investigate customized typing rules, which model Python dynamic duck typing more precisely. I.e. it should be sometimes possible to prove that...

One tricky aspect here is that static type checking depends on how actually full phase specification is constructed from relevant phase definitions. E.g. in the example above, one additionally re-define...

As far as I remember, fork choice logic depends rather on `BeaconBlockHeader` and doesn't really need `BeaconBlockBody` contents, just its `hash_tree_root`. And the former is less likely to change between...

`state_transition` is also called by `compute_new_state_root` which specifies how a validator should compute state_root. So, it also should be updated, if `pre_state.slot < b.slot` moved to `on_blocks`.

As for preventing DoS attacks, I think it's better done on the implementation level. There are three kind of outcomes of `on_block` (and `on_attestation`): valid, invalid or 'early'. The latter...