Lightclient, BeaconState and aggregation

[mratsim]

Looking at the current BeaconState (https://github.com/ethereum/eth2.0-specs/blob/c1a3b29145c84c6ac4422314b7b54898ac9f6693/specs/core/0_beacon-chain.md), the fields are defined the following way:

{
    # Misc
    'slot': 'uint64',
    'genesis_time': 'uint64',
    'fork_data': ForkData,  # For versioning hard forks

    # Validator registry
    'validator_registry': [ValidatorRecord],
    'validator_registry_latest_change_slot': 'uint64',
    'validator_registry_exit_count': 'uint64',
    'validator_registry_delta_chain_tip': 'hash32',  # For light clients to track deltas
    ...
}

And BeaconBlocks are defined this way:

{
    ## Header ##
    'slot': 'uint64',
    # Skip list of ancestor beacon block hashes
    # i'th item is the most recent ancestor whose slot is a multiple of 2**i for i = 0, ..., 31
    'parent_root': 'hash32',
    'state_root': 'hash32',
    'randao_reveal': 'hash32',
    'candidate_pow_receipt_root': 'hash32',
    'signature': ['uint384'],

    ## Body ##
    'body': BeaconBlockBody,
}

Notice that it's mentioning signature and not aggregate_signature like in SlashableVoteData and Attestation so it may be quite huge.

What is the state that light clients must keep track of?

[JustinDrake]

it may be quite huge

signature is the proposer signature. It is a single signature from just one party and is 96 bytes. The aggregate signatures are in the attestations.

[arnetheduck]

I think some of this confusion might be because of how the signature serialization is specified: as an open-ended list of uint384 - it might make sense to be more specific here once the serialization settles down, and possibly have a custom serialization type for signatures and keys, much like we have hash32

[JustinDrake]

@djrtwo Can we specify the signature as a ('uint384', 'uint384')?

(Typo edited.)

[mratsim]

uint384 or hash48 would be better

[djrtwo]

As a fixed tuple? We don't currently have support for this in SSZ

Could define a new container type Signature:

{
    'z1': 'uint384',
    'z2': 'uint384',
}

This would also require slight modifications to either the functions in bls_signature.md or how we pass params into the functions when calling

[JustinDrake]

@djrtwo More verbose but feels like a small win :)

[arnetheduck]

I guess this is where I have to make the mandatory notice that an object adds 4 bytes to the serialization over a custom type (uint768?). That said, I don't think this is a very convincing argument given the fairly limited use of signatures - I'd consider it's a win in terms of clarity however. What would be done with public keys in this scenario? remain a single uint384?

[arnetheduck]

one option is to move away from hash32 (in bytes) and uint384 (in bits) and instead settle on a single, fixed-length array type (bytesNN) that we could use for situations like this.

[hwwhww]

In summary:

1. Option 1:
   • pubkey: uint384
   • signature: list of uint384
2. Option 2:
   • pubkey: uint384
   • signature: uint768
3. Option 3:
   • pubkey: bytes48
   • signature: bytes96
4. Option 4:
   • pubkey: uint384
   • signature: Signature, where Signature is:

   {
       'z1': 'uint384',
       'z2': 'uint384',
   }

5. Option 5:
   • pubkey: bytes48
   • signature: Signature, where Signature is:

   {
       'z1': 'bytes48',
       'z2': 'bytes48',
   }

Any other options?
(edited: added option 5 per #308 (comment))

If we use (4), IMO I don't want to mix SSZ serialization object into BLS spec, it's should be isolated.

[djrtwo]

Option 5: same as option 4 but with bytes48 as the two point types in Signature

[djrtwo]

I'm in favor of defining bytesNN type in SSZ and also using a Signature datastructure with two bytes48 points (z1, z2).

Agreed @hwwhww. Should keep SSZ datastructures isolated in the core spec

[JustinDrake]

This is being addressed by #348. I think the consensus is to use bytes96 for signatures. Feel free to reopen :)