Header/Block traits doesn't enable flexibility

[kayabaNerve]

The Header/Block traits, as it is today, appears largely pointless. It defines a new taking, and getters/setters for:

• The block number
• The parent hash
• The extrinsics root
• The state root
• The digests

1. This makes it impossible to create a header with additional fields, as there's no way for frame_system to actually construct such a header. frame_system would either need to fetch additional arguments via a hook in its config OR would have to take in a header on initialize (as executive does), keep it through the block's runtime, and then not create a new header on finalize yet instead simply set the state and extrinsics roots (preserving all other fields as passed in). Alternatively, all extra fields can be shoved into the heap-allocated digests with consensus rules to ensure their presence for all valid blocks?

2. This makes it impossible to include additional fields in the block itself without abusing the extrinsics/state root. For the former, all distinct fields may be shoved into extrinsics. For the latter, on block initialize, the state can be populated with the fields exactly causing a state root mismatch if the body is different (though this can only be discovered after execution, not prior, as the extrinsics root allows). While this may be the intended design of the Substrate SDK, it raises the question of the value of Block as a trait at all.

3. This forces the state be merklized and fully committed to, without abuse of the system. This makes sense for the Polkadot ecosystem. This doesn't make sense for all Substrate consumers. At the very least, having the state root getter return an Option (allowing people to omit state roots from the header) would solve this.

This raises notes on the fundamental designs of core types. I don't expect to kick off a massive re-architecture as someone outside the Polkadot ecosystem, especially when all the JAM discussions are ongoing. I did want to raise the questions in-case future development can be more mindful of this (without too much burden on maintainers), or for notes in case I'm missing design elements which justify the current design more than I see (though such notes would be better suited to be sourced from the StackExchange and aren't my primary intent).

Apologies if this is too much of a discussion to be justified here, feel free to close if so.