Closed mratsim closed 5 years ago
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.
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
@djrtwo Can we specify the signature as a ('uint384', 'uint384')
?
(Typo edited.)
uint384
or hash48
would be better
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
@djrtwo More verbose but feels like a small win :)
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
?
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.
In summary:
uint384
uint384
uint384
uint768
bytes48
bytes96
uint384
Signature
, where Signature
is:
{
'z1': 'uint384',
'z2': 'uint384',
}
bytes48
Signature
, where Signature
is:
{
'z1': 'bytes48',
'z2': 'bytes48',
}
Any other options? (edited: added option 5 per https://github.com/ethereum/eth2.0-specs/issues/308#issuecomment-450744318)
If we use (4), IMO I don't want to mix SSZ serialization object into BLS spec, it's should be isolated.
Option 5: same as option 4 but with bytes48
as the two point types in Signature
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
This is being addressed by #348. I think the consensus is to use bytes96
for signatures. Feel free to reopen :)
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:
And BeaconBlocks are defined this way:
Notice that it's mentioning
signature
and notaggregate_signature
like inSlashableVoteData
andAttestation
so it may be quite huge.What is the state that light clients must keep track of?