Invalid Block on channel [%s]. Header must be different from

Error message

Invalid Block on channel [%s]. Header must be different from nil.

What it means

MSPMessageCryptoService.VerifyBlock validates gossip-received blocks against the channel MSP. The first check requires the block to carry a Header; a nil header means the block is malformed and cannot be authenticated. Fabric returns this formatted error naming the channel.

Source

Thrown at internal/peer/gossip/mcs.go:130

	mspIDRaw := []byte(sid.Mspid)
	raw := append(mspIDRaw, sid.IdBytes...)

	// Hash
	digest, err := s.hasher.Hash(raw, &bccsp.SHA256Opts{})
	if err != nil {
		mcsLogger.Errorf("Failed computing digest of serialized identity %s: [%s]", peerIdentity, err)
		return nil
	}

	return digest
}

// VerifyBlock returns nil if the block is properly signed, and the claimed seqNum is the
// sequence number that the block's header contains.
// else returns error
func (s *MSPMessageCryptoService) VerifyBlock(chainID common.ChannelID, seqNum uint64, block *pcommon.Block) error {
	if block.Header == nil {
		return fmt.Errorf("Invalid Block on channel [%s]. Header must be different from nil.", chainID)
	}

	blockSeqNum := block.Header.Number
	if seqNum != blockSeqNum {
		return fmt.Errorf("Claimed seqNum is [%d] but actual seqNum inside block is [%d]", seqNum, blockSeqNum)
	}

	// - Extract channelID and compare with chainID
	channelID, err := protoutil.GetChannelIDFromBlock(block)
	if err != nil {
		return fmt.Errorf("Failed getting channel id from block with id [%d] on channel [%s]: [%s]", block.Header.Number, chainID, err)
	}

	if channelID != string(chainID) {
		return fmt.Errorf("Invalid block's channel id. Expected [%s]. Given [%s]", chainID, channelID)
	}

	// - Unmarshal medatada

View on GitHub (pinned to 2736b63f8f)

Solutions

Check upstream block unmarshalling — a failed proto.Unmarshal likely produced a headerless block
Verify the gossip payload source; re-fetch the block from orderer/committer
Add a nil-header guard where the block is created before handing it to VerifyBlock

Example fix

// before
err := cryptoService.VerifyBlock(channelID, seq, block)
// after
if block == nil || block.Header == nil {
    return fmt.Errorf("block has no header; refusing verification")
}
err := cryptoService.VerifyBlock(channelID, seq, block)

Defensive patterns

Strategy: type-guard

Validate before calling

func verifiableBlock(b *pcommon.Block) bool {
    return b != nil && b.Header != nil
}

Type guard

func hasHeader(b *pcommon.Block) bool {
    return b != nil && b.Header != nil
}

if !hasHeader(block) {
    return errors.New("cannot verify block: missing header")
}
err := cryptoService.VerifyBlock(chainID, seqNum, block)

Try / catch

if err := cryptoService.VerifyBlock(chainID, seqNum, block); err != nil {
    if strings.Contains(err.Error(), "Header must be different from nil") {
        log.Warnf("dropping malformed block %d on %s", seqNum, chainID)
        return nil
    }
    return err
}

Prevention

Always unmarshal blocks with proto.Unmarshal and check the error before verification
Never pass zero-value common.Block structs to crypto services
Log block provenance to catch corrupt gossip payloads early

When it happens

Trigger: VerifyBlock called (by gossip state/message validation) with a *pcommon.Block whose Header field is nil — typically a deserialization failure or a synthesized/empty block passed in by a caller.

Common situations: Corrupt block delivered over gossip; bug in code constructing blocks without headers; unmarshalling errors silently swallowed upstream so a zero-value Block reaches verification.

Related errors

AI-assisted analysis of hyperledger/fabric@2736b63f8f (2026-09-04). Data as JSON: /api/errors/3eae949332ce8839. Report an issue: GitHub.