[GP Sec 6.4] Block Sealing

[sourabhniyogi]

This PR contains community-generated test vectors concerning Block sealing for primary (T=1) and fallback (T=0) cases, how to interpret their fields, and how to verify seals. The same data can be used to generate seals.

JAM Graypaper Sec 6.4 is the primary section being tested.

If you find issues, let us know in the PR and we'll try to correct them within a day or two.

If you think they are reasonable and can pass them, say so!

Overview

When sealing a block, as per GP Section 6.4, two VRF Signatures are produced by the block author using their Bandersnatch key:

• H_s – the seal proof
• H_v – the entropy source proof

The material being signed and their various inputs (c, m) depend on the block header, ticketID (T=1), entropy (eta3') and in the case of H_s, on H_v itself.

JSON Structure

Each JSON file generated has the following fields:

JSON Key	Description
bandersnatch_pub	Hex-encoded Bandersnatch public key of the block author. In production, you typically store just the public portion.
bandersnatch_priv	Hex-encoded Bandersnatch secret key (private key). Storing private keys in production JSON is not recommended; it is done here for debugging purposes.
ticket_id	Hex-encoded ticket identifier used for verifying or associating with a block’s VRF entropies.
attempt	Integer attempt number (0 or 1)
c_for_H_s	VRF input c used to generate H_s.
m_for_H_s	VRF message m used to generate H_s.
H_s	Hex-encoded proof output for H_s (the VRF signature/proof itself).
c_for_H_v	VRF input c used to generate H_v.
m_for_H_v	VRF message m used to generate H_v. (Often empty in primary epoch flows.)
H_v	Hex-encoded proof output for H_v (the VRF signature/proof itself).
eta3	Eta_3' -- concatenated in VRF Input material.
T	Integer indicator for epoch type (1 = primary epoch, 0 = fallback epoch).
header_bytes	Hex-encoded serialized block header bytes at the time of sealing.

This is contributed by Colorful Notion (JAM DUNA) and are not official.

Development Keys

In this PR are 6 development private / public keys derived from a "key" utility that relies on programmatically generatable seeds. All the block authoring and seals rely on these development keys. See key for details.

JAM implementers will likely need a working FFI into the W3F ietf library to pass this test vector and specifically pass the Safrole STF test vectors.

Motivation

Being able to verify and generate block seals of valid blocks are a key step of M1 and M2 competence.

We generated this to support our ability to work with others with Importblocks where any fuzzed block has to be resealed.

[arjanz]

I can confirm that I was able to verify H_s, H_v and ticket ID using the provided data. The only parameter not explicitly mentioned is the ticket attempt. While it’s easy to infer from the other data, it would be more convenient if it were included.

c_for_H_s, m_for_H_s, c_for_H_v, m_for_H_v are maybe a bit redundant.

[sourabhniyogi]

Excellent - good idea to add in attempt number, will do that!

[sourabhniyogi]

c_for_H_s, m_for_H_s, c_for_H_v, m_for_H_v are maybe a bit redundant.

Definitely but it's useful for pedagogical and pedantic completeness, relative to just having H_s and H_v alone - we took a "show every intermediate step" rather than "let's see if you are smart enough to figure it out" approach to leave no one behind ;)

[sourabhniyogi]

The only parameter not explicitly mentioned is the ticket attempt. While it’s easy to infer from the other data, it would be more convenient if it were included.

Added attempt -- thank you for the suggestion!

[greywolve]

Thanks for these, we are able to pass them all. :)