Make lightclient patch pass the linter

[hwwhww]

Make #2130 executable + pass the linter.
Note: this PR doesn't enable lightclient fork spec tests.

[JustinDrake]

class BeaconBlockBody(phase0.BeaconBlockBody): is so much cleaner than repeating all the properties!

@protolambda: Can we do some Python magic here?

[protolambda]

With python we can do a lot, but the question is if we should. Being implicit would mean we need to spec appending of fields. And then sometimes appending is not the approach we want. Or functionality is not sequential, and we remove a field.

[vbuterin]

The reason why I did the inheriting from phase0 in the original PR instead of repeating properties is not just to cut down the number of lines of code, it's also to make the patch to the spec truly not sequential (ie. if it's implemented after sharding it could still be included as is). This would make it easier for us to work on light client stuff, the merge and sharding in parallel. So it would be really nice if we can make the inheritance work!

[protolambda]

That sounds great, but then do what we want some diamond structure? I.e. phase 0 type inherited by various phase 1 types, and then recombined in the complete phase 1 type? This becomes "the diamond problem" once we start overriding things in different types, which we then need to reconsolidate.

[vbuterin]

Well, I don't support the concept of "phases" anymore, so... 😄

Realistically, once some patch gets implemented, we could just quickly rewrite the other patches to point to the previous patch as a base (eg. s/phase0./lightclient_fork./g), and when writing each individual patch make sure that it is valid under any combination of the other patches.

This does of course assume that the absolute number of patches that are treated this way (as opposed to just being PRs to existing spec as all the beacon chain changes pre-launch were) needs to be very small.

[protolambda]

Ok, implemented it and opened a PR to my SSZ library that we use here in the spec, with support for all this (inheritance, mixins, diamonds): protolambda/remerkleable#8

Please give it a review, and let's discuss on next spec call. It seems small, but it's quite a step away from bare struct definitions.

[hwwhww]

Updates:

• Reverted back to inheritance. Some mypy errors

  eth2spec/lightclient/spec.py:1678: error: Argument "default" to "max" has incompatible type "object"; expected "Eth1Data"
  eth2spec/lightclient/spec.py:1815: error: Unsupported left operand type for - ("object")

  • ^^^^ I saw the errors with SSZ object-oriented-programming protolambda/remerkleable#8 locally.
  • My guess is, it's old issue, remerkleable doesn't fully support mypy (Add SSZ utils to mypy checking scope #1707). We can propbably force casting them, as a workaround.
• Fixed upstream conflicts.
• Enabled lightclient/sync-protocol building. Many linter errors. IMO we can merge this PR into vbuterin-patch-2 now and then fix them in PR Added standalone light client patch #2130. @JustinDrake @vbuterin What do you think?