Alex Vlasov

Unclear atomicity semantics of the beacon chain spec

4

In the [beacon chain specs](https://github.com/ethereum/eth2.0-specs) state updates are sometimes intertwined with assertions within a function. An executable python spec is also constructed from such code fragments. The executability of the...

`custody_bits_blocks` in `Attestation`

1

[Attestation](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase1/beacon-chain.md#extended-attestation) had `custody_bits_blocks`: ``` custody_bits_blocks: List[Bitlist[MAX_VALIDATORS_PER_COMMITTEE], MAX_SHARD_BLOCKS_PER_ATTESTATION] ``` It's used by [is_valid_fraud_proof](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase1/shard-transition.md#verifying-the-proof). Looks like it was dropped during recent merge: it's missing [here](https://github.com/ethereum/eth2.0-specs/blob/a0175ca1b353a1271703bb66f262b9b1e9a4adcc/specs/phase1/beacon-chain.md#extended-attestation). But is present [here](https://github.com/ethereum/eth2.0-specs/blob/50ac8ebb0ccebb0ced41e0471498c422db816856/specs/phase1/beacon-chain.md#extended-attestation).

There are cases in pyspecs (found during static analysis of them), which rely on [duck typing](https://en.wikipedia.org/wiki/Duck_typing). For example, [upgrade_to_altair(phase0.BeaconState)](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/altair/fork.md#upgrading-the-state`) in Altair or [upgrade_to_phase1(phase0.BeaconState)](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/phase1/fork.md#upgrading-the-state) in Phase1. The functions receive an instance...

Typing problems when a container is re-defined in a superseding phase

2

Newer phases re-define containers like `BeaconState`, `BeaconBlockBody`, `AttestationData`, etc. A typical case is adding a new field, however, altering field name/type is possible too. This leads to typing problems in...

Currently, when node starts, fork choice is based on an empty LatestMessages set, since LMs/attestations are not stored on disk explicitly. However, on-chain attestations (inside blocks) are kept in the...

`CachingBeaconChainSpec::hash_tree_root` can be passed with a mutable object, e.g. `MutableBeaconState` or `WriteList`/`WriteVector`. Thus it can return wrong value, if the mutable object is modified, since the caching code uses `Object`...

MultiValidatorService implements a check, ensuring that a proposer or an attester can propose/attest only once per slot. However, [validator spec](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/validator/0_beacon-chain-validator.md#how-to-avoid-slashing) slashing conditions are defined per epoch. I.e. there should not...

Since beacon objects are immutable, message signing is typically performed with the following steps: 1 construct an object with empty signature 2 sign the object (construct an appropriate signature) 3...

There are two main StateTransition functions: preBlock (empty slot) and perBlock. However, their construction somewhat clumsy and non-uniform accross code base. E.g. ``` initialTransition = new InitialStateTransition(chainStartEvent, spec); perSlotTransition =...

[fork_choice/get_head](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/core/0_fork-choice.md#get_head) specifies, that when choosing the heaviest child, ties should be broken lexicographically: > \# Sort by latest attesting balance with ties broken lexicographically However, Harmony implementation sorts by latest...