Add beacon chain / eth2.0 related NewType

[hwwhww]

What is wrong?

#1373 (comment)
To make the types more explict!

How can it be fixed

1. Time unit - Second - and also can be used for PoW chain?
2. For beacon chain, some other NewType candidates: Slot, ShardID. And with the latest spec: ValidatorStatus, SpecialRecordType, ValidatorSetDeltaFlag.
3. EDIT: Move to ethereum/eth-typing/

[hwwhww]

@cburgdorf is there any known solution to define: (i) the length of an integer (ii) unsigned/signed integer via type hinting?
p.s. I searched mypy but didn't find a similar use case like ours. e.g., define Slot is uint64.

[cburgdorf]

is there any known solution to define: (i) the length of an integer (ii) unsigned/signed integer via type hinting?

No, mypy can not do these things. What it can do is to allow you different types for different intents and ensure to trace the flow of these to prevent the wrong one ending up at a wrong place.

Consider this:

def create_some_thing_unsigned() -> int:
    ...

def create_some_thing_signed() -> int:
    ...

def consume_something_unsigned(unsigned: int):
    ...

clearly we want to prevent the following situation:

x = create_something_signed()
consume_something_unsigned(x)  # runtime crash!

Mypy can help you with this if you create a NewType.

UnsignedInt = NewType('UnsignedInt', int)

def create_some_thing_unsigned() -> UnsignedInt:
    ...

def create_some_thing_signed() -> int:
    ...

def consume_something_unsigned(unsigned: UnsignedInt):
    ...

Now, if you'd try this again, mypy would yell at you because it knows that x is not of type UnsignedInt.

x = create_something_signed()
consume_something_unsigned(x)  # development time mypy error!

[hwwhww]

@cburgdorf thanks for the reply!

Re: > Move to ethereum/eth-typing/

What do you think about making the beacon chain new types in eth/beacon/typing.py temporarily, and then move to eth-typing once we settle down? I want to sort out what are the new types we need.

The types that I think we'd need:

SlotNumber = NewType('SlotNumber', int)  # uint64
ShardNumber = NewType('ShardNumber', int)  # uint64
BLSPubkey = NewType('BLSPubkey', int)  # uint384
BLSSignature = NewType('BLSSignature', Tuple[int, int])  # Tuple[uint384, uint384]
ValidatorIndex = NewType('ValidatorIndex', int)  # uint24
Bitfield = NewType('Bitfield', int)  # uint64

The types that I'm not 100% sure:

AmountInEther = NewType('AmountInEther', int)  # uint64
AmountInGwei = NewType('AmountInGwei', int)  # uint64

[cburgdorf]

What do you think about making the beacon chain new types in eth/beacon/typing.py temporarily, and then move to eth-typing once we settle down?

Yes, that would be my preferred approach as well 👍

The types that I'm not 100% sure:

Ensuring that an API that expects Gwei isn't called with Ether is exactly what NewTypes are for. The canonical example is usually this NASA bug where an API was called with miles that expected kilometers and caused the rocket to crash. This falls into the same category.

I would just simplify the names to

Ether = NewType('Ether', int)  # uint64
Gwei = NewType('Gwei', int)  # uint64

[ChihChengLiang]

Working on this

[ralexstokes]

another NewType that would be great is BLSSignature

@hwwhww laid out this plan:

• Determine the type of signature on specs - both phase 0 spec and BLS spec
• e.g. EMPTY_SIGNATURE is now [bytes48(0), bytes48(0)] while all the SSZ signature fields are [uint384] now.

And then we can create a BLSSignature type for use in various places (like the beacon chain).

I'm leaving a comment so this task can be rolled into this issue. I'll take a look at defining the actual signatures if I get some time

EDIT: related ethereum/consensus-specs#308