[AndrewWestberg]

Summary

Extend the node’s bulk credentials loader to accept optional BLS signing keys per pool. This lets pools loaded from the same file use distinct Leios voting keys while preserving compatibility with existing bulk files.

Each entry now accepts either:

[opcert, vrf, kes]
[opcert, vrf, kes, bls]

The optional fourth element accepts a single embedded BLS signing-key text envelope or an array of envelopes. Omission, null, and [] mean no BLS keys. Entries with and without BLS keys can be mixed in the same file.

Behavior

• Preserve key order and attach each pool’s BLS keys to its own consensus leader credentials.
• Reject malformed entries and invalid supplied keys rather than silently discarding them or returning partial credentials.
• Report invalid BLS envelopes with zero-based entry/key locations, such as <file>.1bls.1.
• Leave singleton CLI credentials, consensus behavior, and existing bulk-file generators unchanged.

This format extension applies only to the node loader; independent tools that require triples remain unchanged. Operators should use distinct BLS keys for different pools. Key registration and committee membership remain operator responsibilities.

Verification

• Production library build passed.
• cabal test cardano-node:test:cardano-node-test --test-show-details=direct passed, including new coverage for:
  • Mixed legacy, singleton-BLS, and multiple-BLS entries, checking exact verification-key identities and order.
  • Omitted, null, and empty BLS values, plus an empty outer array.
  • Malformed entry shapes and non-array input.
  • Wrong key types and invalid CBOR, checking indexed error locations.
• Direct GHCi smoke exercised the production loader through real temporary files, outside Hedgehog. Three pools returned the expected ordered verification-key lists for seeds [[11], [21,22], []]; the identity comparison returned True.