Block Structure

Question

I'm comparing the whitedoc to output from head, eg:

./alphanet.sh head | jq
{
  "protocol": "PsddFKi32cMJ2qPjf43Qv5GDWLDPZb3T3bF6fLKiF5HtvHNU7aP",
  "chain_id": "NetXgtSLGNJvNye",
  "hash": "BKxrfgYNdHGWn3YnVpa1tnvgoxavndMNBYGh2me9XKtsDEx8d7w",
  "level": 4510,
  "proto": 1,
  "predecessor": "BMA56gCA6YhWxF2PYE2ZCqP2BDGNe8t9W4vCqmZk7i3FaoV8AbF",
  "timestamp": "2018-12-02T20:36:48Z",
  "validation_pass": 4,
  "operations_hash": "LLoZZffQfMi2zx7yjkzgxQJ32GKtQDUgZrfzM3xQCzmsCLtGFW72m",
  "fitness": [
    "00",
    "000000000001ec0d"
  ],
  "context": "CoVFUdktdZxEqUBhWe7AVx33tFUPK5af3qFigiS8uqBhsk9cbSd8",
  "priority": 0,
  "proof_of_work_nonce": "000000032b0e061b",
  "signature": "sigfGKgAq2ZqVo4mJnrchVUJV4Hg4ifbxc6BbgWYWVye53DhseMGLy6ZSYichty8KrJkjPdFFip4t64whrR1CtazRTrTkfJb"
}

Some of these fields are explained in the whitedoc, chain_id and hash seem to be missing. Couple of questions:

• Is there any better, more complete documentation? (Looking for thorough definitions of context, fitness, operations_hash, etc.)
• The whitedoc states that it is describing the protocol header for alpha. Is there a difference between alpha and mainnet?

Answer 1

As show in the official documentation (click "JSON Output" in order to see the details) the structure of the block header in proto 003 is

$block_header
  $Chain_id:
    /* Network identifier (Base58Check-encoded) */
    $unistring
  $Context_hash:
    /* A hash of context (Base58Check-encoded) */
    $unistring
  $Operation_list_list_hash:
    /* A list of list of operations (Base58Check-encoded) */
    $unistring
  $Signature:
    /* A Ed25519, Secp256k1 or P256 signature (Base58Check-encoded) */
    $unistring
  $block_hash:
    /* A block identifier (Base58Check-encoded) */
    $unistring
  $block_header:
    { "protocol": "PsddFKi32cMJ2qPjf43Qv5GDWLDPZb3T3bF6fLKiF5HtvHNU7aP",
      "chain_id": $Chain_id,
      "hash": $block_hash,
      "level": integer ∈ [-2^31-2, 2^31+2],
      "proto": integer ∈ [0, 255],
      "predecessor": $block_hash,
      "timestamp": $timestamp,
      "validation_pass": integer ∈ [0, 255],
      "operations_hash": $Operation_list_list_hash,
      "fitness": $fitness,
      "context": $Context_hash,
      "priority": integer ∈ [0, 2^16-1],
      "proof_of_work_nonce": /^[a-zA-Z0-9]+$/,
      "seed_nonce_hash"?: $cycle_nonce,
      "signature": $Signature }
  $cycle_nonce:
    /* A nonce hash (Base58Check-encoded) */
    $unistring
  $fitness:
    /* Block fitness
       The fitness, or score, of a block, that allow the Tezos to decide
       which chain is the best. A fitness value is a list of byte sequences.
       They are compared as follows: shortest lists are smaller; lists of the
       same length are compared according to the lexicographical order. */
    [ /^[a-zA-Z0-9]+$/ ... ]
  $int64:
    /* 64 bit integers
       Decimal representation of 64 bit integers */
    string
  $timestamp: $timestamp.rfc || $int64
  $timestamp.rfc:
    /* RFC 3339 formatted timestamp
       A date in human readble form as specified in RFC 3339. */
    $unistring
  $unistring:
    /* Universal string representation
       Either a plain UTF8 string, or a sequence of bytes for strings that
       contain invalid byte sequences. */
    string || { "invalid_utf8_string": [ integer ∈ [0, 255] ... ] }

You can also recover this information directly from your tezos node using the following rpc call

 ./tezos-client rpc schema get /chains/main/blocks/head/header