Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Complete Block Header #1161

Open
charithabandi opened this issue Dec 16, 2024 · 2 comments
Open

Feature Request: Complete Block Header #1161

charithabandi opened this issue Dec 16, 2024 · 2 comments
Labels
enhancement New feature or request

Comments

@charithabandi
Copy link
Contributor

charithabandi commented Dec 16, 2024

Describe the Feature

Recheck on the contents of the Block Header

We currently have the below header

type BlockHeader struct {
        Version     uint16
	Height      int64
	NumTxns     uint32
	PrevHash    Hash // previous block's hash
	PrevAppHash Hash // app hash after last block
	Timestamp   time.Time
	MerkleRoot  Hash
}

Few other fields to consider either as a part of the block header or as a commit Info (lastCommitInfo)

  • Validator votes with signature
  • App Hash should include (user dataset changes, accounts changes, chain state changes, validator updates, consensus params updates, TX results hash)
@charithabandi charithabandi added the enhancement New feature or request label Dec 16, 2024
@jchappelow
Copy link
Member

jchappelow commented Dec 16, 2024

As discussed in person, I think the last commit info should be in an adjacent struct. The block hash is the hash of the serialized block header, and it would be strange to have the block proposal including a "template" block header rather than the complete block header. The results of consensus for that feel like a result of the process rather than part of this block. EDIT: last commit hashes could go in the block though. I was referring to the outcome of consensus process on the current block being accessible by separate endpoint or adjacent if it's committed.

@jchappelow
Copy link
Member

jchappelow commented Dec 17, 2024

For reference and inspiration, here's comet's block Header: https://github.com/cometbft/cometbft/blob/20580795f068c2ade3530ae6647ceb97603a29e7/types/block.go#L331-L357
It looks like everything is either created by the proposer or derived from "last" block or "last" block's consensus approvals, even the results hash is "last".

go-ethereum's: https://github.com/ethereum/go-ethereum/blob/1321a4252544c6451ed1867f6d2714f0fd6b30a9/core/types/block.go#L75-L109
The ParentBeaconRoot field is probably the closest thing to a record of the consensus approvals (from beacon chain)

Despite the potential waste, we could have leader address alongside leader signature. Alternatively, a commit info endpoint could include that along with outcomes of consensus for the block, if committed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants