3

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?
0

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.