evm irrelevant bock fields

[DreamWuGit]

there are some block fields as following(mark with prefix *) which are evm irrelevant, in other words, evm do not use or access them directly, and they ought to be not include in evm circuit, however, does the Layer1 contract will need them eventually for sanity checking ?

// Header represents a block header in the Ethereum blockchain.
type Header struct {
    ParentHash  common.Hash    `json:"parentHash"       gencodec:"required"`
    *UncleHash   common.Hash    `json:"sha3Uncles"       gencodec:"required"`
    Coinbase    common.Address `json:"miner"            gencodec:"required"`
    *Root        common.Hash    `json:"stateRoot"        gencodec:"required"`
    *TxHash      common.Hash    `json:"transactionsRoot" gencodec:"required"`
    *ReceiptHash common.Hash    `json:"receiptsRoot"     gencodec:"required"`
    *Bloom       Bloom          `json:"logsBloom"        gencodec:"required"`
    Difficulty  *big.Int       `json:"difficulty"       gencodec:"required"`
    Number      *big.Int       `json:"number"           gencodec:"required"`
    GasLimit    uint64         `json:"gasLimit"         gencodec:"required"`
    GasUsed     uint64         `json:"gasUsed"          gencodec:"required"`
    Time        uint64         `json:"timestamp"        gencodec:"required"`
    *Extra       []byte         `json:"extraData"        gencodec:"required"`
    *MixDigest   common.Hash    `json:"mixHash"`
    *Nonce       BlockNonce     `json:"nonce"`

    // BaseFee was added by EIP-1559 and is ignored in legacy headers.
    BaseFee *big.Int `json:"baseFeePerGas" rlp:"optional"`
}

from my current perspective, for the stateRoot, transactionsRoot, receiptsRoot seems make sense to layer1, but others like Bloom, nonce are trivial to layer1 . Just some thinking as to this aspect, not urgent for current stage, we can review it in the future.

[barryWhiteHat]

I think Root is still important for deposits and things like that. Also some smart contract use the current or previous roots to look things up. Same with tX_hash

Totally agree on the rest would also include Difficulty.

For these we can probably set them to a dummy constants for zkrollup use case.

[DreamWuGit]

Yes， I say stateRoot for Root, transactionsRoot for TxHash :), moreover ,I see the ReceiptHash also count for tx logs which evm operates to write.

[barryWhiteHat]

I would say that we should treat the irrelevant block feilds like post merge eht does

https://github.com/appliedzkp/zkevm-specs/issues/98

That way its easier for devs to deploy their apps without worrying about these irreverent fields.