post-state-root: implement block production

[pugachAG]

Extend block production logic to support post-state-root version

[Longarithm]

My summary of necessary changes:

• prev_validator_proposals field goes to BlockInfo::proposals, used in epoch manager, validated in validate_chunk_headers. It can stay unchanged, but it feels more natural to propagate most recent proposals, available in validator_proposals in post-state-root world. New name should be validator_proposals. Edge case: on first block with post-state-root we should add both prev and current proposals.
• gas_price - this will not define gas_price in post-state-root world, so I would change it to next_gas_price to reflect reality. And use newly introduced gas_used and balance_burnt, indeed. Edge case: on first block with post-state-root, aggregate both prev_gas_used and gas_used.

Not that necessary changes - we can remove challenges_root and challenges_result, as we don't plan to implement challenges anymore. We could consider the same about block_ordinal and epoch_sync_data_hash.

Full fields description:

BlockHeaderInnerLite

• height - very widely used. Defines block/chunk producer, finality conditions. In pre-state-root world defines height of chunk inclusion. No need to change.
• epoch_id - defines current validator set. Can be retrieved using prev block hashes until we reach epoch start, but it’s okay to keep signing it. No need to change.
• next_epoch_id - similar, not impacted by post-state-root.
• prev_state_root - can be retrieved by ShardChunkHeaders, but actually needed for light clients as we want them to process as few data as possible. Can be changed to post_state_root later, but bridges may need to be updated. Depends on how field is used.
• prev_outcome_root - same as above.
• timestamp - called in BlockHeader::timestamp. Participates in validation conditions: 1) ts are strictly increasing; 2) not increases by more than 2 minutes at once. Exposed to contracts. For post-state-root, we may change timestamp passed to runtime: https://github.com/near/nearcore/blob/a27075f1052c11b6acae94053657d284a9b94018/chain/chain/src/chain.rs#L4194 by passing prev block timestamp instead, to be consistent with old API. But field doesn't change, except maybe adding 1 unit on edge case.
• next_bp_hash - doesn't change.
• block_merkle_root - doesn't change.

BlockHeaderInnerRestV5

• block_body_hash - doesn't change
• prev_chunk_outgoing_receipts_root - doesn't change. Publicly used ONLY for state sync, see ShardStateSyncResponseHeader. Not sure why it is needed there. Can be superseded by new field outgoing_receipts_root which would make more sense.
• chunk_headers_root - doesn't change. Maybe it is needed for faster state sync to prove only one chunk header without need to download all chunk headers.
• chunk_tx_root - doesn't change and has no usecases. Block body has chunk headers anyway.
• challenges_root - will be useless
• random_value - needs to change
• prev_validator_proposals - see above.
• chunk_mask - main purpose is to init BlockInfo::chunk_mask and compute produced/expected stats. No need to change.
• gas_price - see above.
• total_supply - is adjusted by minted_amount on every epoch start. Can be retrieved from epoch start, but I don't mind signing it each block.
• challenges_result - will be useless
• last_final_block - used very widely. I think it is very useful, as it gives finality info right away. We don't need to change it as stateless validation has nothing to do with finality.
• last_ds_final_block - used to recompute last_final_block, stays as is
• block_ordinal - unused, unchanged
• prev_height - I see Robin touched it recently. Looks like it is used to determine approval kind, this is fine.
• epoch_sync_data_hash - unused
• approvals - will contain chunk endorsements later, but for now has only block approvals which don't change.
• latest_protocol_version - stays as is.

[Longarithm]

After a bit of discussions, I think that there are no necessary fields to change.

Explanation

Validator proposals

Let's stop caring about what's the name of the field. Focus on invariant instead, which is:

Validator proposals must be applied at the same time to EpochManager (during add_validator_proposals) and State (during chunk processing) This is handled by 2-staged processing of proposals: 1) Stake Action is processed during applying chunk. Its result is saved as "validator proposal" and stored to ApplyChunkResult, which then goes to ChunkExtra. 2) On applying next block we take these previously saved proposals and: 2a) apply them to EpochManager 2b) apply them to State during processing of respective chunk

So nothing changes here. With post-state-root, we can just pass proposals using chunk header itself (new validator_proposals field), not chunk extra. Changing block header contents would be actually a mistake.

Gas price

I assumed that in pre-state-root, for applying chunk, gas price is taken from the block which contains this chunk, as we already know the block. But it’s not the case. We take gas price from previous block: https://github.com/near/nearcore/blob/9c8d0bbec6a71876bb3317db2ade425f0077a184/chain/chain/src/chain.rs#L4120 I don't know why. But in both pre and post state roots previous block exists anyway, so we can avoid any changes there. (@pugachAG: we can still just rename this field to next_gas_price to avoid further confusion)