Eth2.0-specs: New beacon block format

[JustinDrake]

This is mostly a heads-up for implementers that we are moving to a new BeaconBlock format:

{
    'slot': 'uint64',
    'parent_root': 'hash32',
    'state_root': 'hash32',
    'deposit_root': 'hash32',
    'randao_reveal': 'hash32',
    'signature': ['uint384'],
    'body': {
        'proposer_slashing': [ProposerSlashingObject],
        'casper_slashing': [CasperSlashingObject],
        'attestations': [AttestationObject],
        'deposits': [DepositObject],
        'exits': [ExitObject],
    },
}

Several things are going on here:

• [x] Unify attestations with the other beacon transactions (currently known as "specials")
• [x] Stricter typing for beacon transactions
• [x] Merge the logic around checking maximum number of transactions per kind
• [ ] Remove ancestor_hashes from the blocks. A historical block accumulator will go in the state instead.
• [x] Order the beacon transaction kinds so as to minimise edge cases and attacks
• [x] Cleaner naming
• [x] Put all beacon transactions in a body for light-client friendliness
• [x] Clean conceptual separation of the "header" (the six fields from slot to signature) and the body

[hwwhww]

Suggestion:

1. Add 'body_root': 'hash32' in BeaconHeader fields, where body_root is the hash of corresponding BeaconBody.
2. Use the hash of BeaconHeader instead of the hash of BeaconBlock to represent the "Beacon Block Hash".

I feel that will be more light-client friendly and data storing friendly.

[JustinDrake]

I feel that will be more light-client friendly and data storing friendly.

Why? The tree hashing algorithm plus the header and body separation makes the data structure pretty light-client friendly.

[hwwhww]

So that the light-client can only download the headers and the certain bodys when they need?

[JustinDrake]

So that the light-client can only download the headers and the certain bodys when they need?

Light clients can download the headers together with body Merkle roots. That's enough to calculate block_hash and download specific bodies trustlessly.

[vbuterin]

Clean separation of header and body, somewhat more light-client friendly

I actually don't like this :cry:

Our current approach is already very light client friendly because of how SSZ tree hashing works: if the header contains the body, then at hashing level the root of the body gets into the header as a 32 byte hash. So the status quo (plus making the body be a field of the block) is already exactly what @hwwhww is proposing :smile:

I don't think (header, body) pairs are quite as light client friendly because to chain them together you still need to dig into the header to find out what the parent is, so the end result is that clients are downloading the same structure except the formatting is more complicated.

[JustinDrake]

I actually don't like this 😢

I agree that the header field doesn't add much, other than a bit of conceptual clarity. I'm happy with or without it.

[hwwhww]

Light clients can download the headers together with body Merkle roots.

Then the full node will need to store the body merkle roots separately for serving light client?

The easiest DB schema for full node is:

1. slot -> beacon_hash
2. beacon_hash -> BeaconBlock

But it's not ideal for serving the light clients.

If we have body_root in BeaconHeader, the DB schema in my mind will be (very similar to eth1.0):

1. slot -> beacon_header_hash
2. beacon_header_hash -> BeaconHeader
3. beacon_header_hash_to_body -> BeaconBody

If we don't have body_root in BeaconHeader, not quite sure if it's the correct solution:

1. slot -> beacon_block_hash
2. beacon_block_hash_to_header -> BeaconHeader
3. beacon_block_hash_to_body -> BeaconBody
4. beacon_block_hash_to_body_hash -> beacon_body_hash

[vbuterin]

Do we want an explicit "header contains root of body" structure, or for the header to just contain the body, as that has literally the exact same effect due to SSZ tree hashing? What are the tradeoffs here?

[hwwhww]

/cc @rawfalafel @mkalinin

[djrtwo]

Seems like the following gives us what we want as long as blocks can be served with a hash for body if requested

#### BeaconBlock

{
    'slot': 'uint64',
    'parent_hash': 'hash32',
    'state_root': 'hash32',
    'randao_reveal': 'hash32',
    'candidate_pow_receipt_root': 'hash32',
    'signature': ['uint384'],
    'body': BeaconBlockBody,
}

[hwwhww]

blocks can be served with a hash for body if requested

If it's in this schema, the light client will need:

1. basic header fields
   'slot': 'uint64', 'parent_hash': 'hash32', 'state_root': 'hash32', 'randao_reveal': 'hash32', 'candidate_pow_receipt_root': 'hash32', 'signature': ['uint384'],
2. block hash
3. block body hash for verifying the block hash

If it's for light client syncing, IMO the full node won't generate/wrap the response data in runtime. So they will store the body hash in somewhere. 😄

[hwwhww]

/cc @zsfelfoldi

[mkalinin]

Do we want an explicit "header contains root of body" structure, or for the header to just contain the body, as that has literally the exact same effect due to SSZ tree hashing? What are the tradeoffs here?

If we want to have an option to work with chain of headers as an alternative to chain of blocks then the structure with root of body in the header is the only possible way of achieving that. Downloading chain of headers instead of blocks could potentially reduce network load since headers have small and constant size.

At the moment, it's difficult to say whether chain of headers will be important thing or not. For example, it's used by eth1.0 fast sync algorithm to verify that chain that pivot block is part of is a valid PoW chain with correct genesis. This is essential thing for the fast sync, especially when chain data is huge. AFAIR, it takes about a half of an hour to download all headers and several hours to download bodies on the main net. Chain of headers is also used by a full sync to handle forks, hence, bodies are downloaded only when header chain passes reorg safe threshold.

But these examples are from eth1.0. And it's not necessary that beacon chain sync will use same approaches as eth1.0 sync does. And in my opinion it's too early to judge on correct block/header structure at the moment, this is more about architectural and design thing that depends on how these structures will be used by a beacon chain sync.

But, if we need to make such decision now it might be useful to keep an opportunity header chains and use header structure with body root in it. It may be changed back when there will be strong understanding that we don't need such feature.

Seems like the following gives us what we want as long as blocks can be served with a hash for body if requested

Won't there be collisions in case of empty bodies or bodies with same specials that seems like a possible case.

Maybe I am missing something but the only difference between this structure https://github.com/ethereum/eth2.0-specs/issues/246#issuecomment-445101678 and plain old BeaconBlock is that body have its own hash and can be requested by that hash. But what about header though? Could it be requested without a body? Header hash calculation depends on hash(body) and verifying that peer responded with requested header would only be possible when body is downloaded.

[JustinDrake]

verifying that peer responded with requested header would only be possible when body is downloaded

No need to download body—the tree hash of body is sufficient.

[mkalinin]

Hm, then block header structure should be as following:

{
    'slot': 'uint64',
    'parent_hash': 'hash32',
    'state_root': 'hash32',
    'randao_reveal': 'hash32',
    'candidate_pow_receipt_root': 'hash32',
    'signature': ['uint384'],
    'body_root': 'hash32'
}

Or there could be two version of this structure, one with body and another one with body_root.

[JustinDrake]

there could be two version of this structure

At the consensus layer I don't see value in adding body_root in the header. If clients want to tack on body_root at the networking/database layer, for sure!

[mkalinin]

At the consensus layer I don't see value in adding body_root in the header

Totally agree. And in terms of consensus structure described in https://github.com/ethereum/eth2.0-specs/issues/246#issuecomment-445101678 looks pretty solid to me.

[djrtwo]

@JustinDrake Do we have consensus on the historic block accumulator? I'm considering closing this issue and making a new one for the parent_hash/block accumulator

[djrtwo]

nevermind, just saw #269

[JustinDrake]

With #269 merged in the only changes I'd like to see are:

• Some renaming: parent_hash => parent_root and candidate_pow_receipt_root => deposit_root
• Some reordering of fields (e.g. have the body fields respect the order in which the processing happens)

[djrtwo]

I'll handle deposit_root and reordering fields.

Did @vbuterin push back on parent_root?

[JustinDrake]

My guess is that he's sold now :) @vbuterin?

[vbuterin]

Yeah, I'm ok with parent_root.

[djrtwo]

The last point in this issue is referenced in #218 and is currently being addressed in PR #269