package tezos-protocol-updater

The maximum size of a block header in bytes.

The maximum size of an operation in bytes.

The number of validation passes (length of the list) and the operation's quota for each pass.

The version specific type of blocks.

Encoding for version specific part of block headers.

A fully parsed block header.

Version-specific side information computed by the protocol during the validation of a block. Should not include information about the evaluation of operations which is handled separately by operation_metadata. To be used as an execution trace by tools (client, indexer). Not necessary for validation.

Encoding for version-specific block metadata.

The version specific type of operations.

Version-specific side information computed by the protocol during the validation of each operation, to be used conjointly with block_header_metadata.

A fully parsed operation.

Encoding for version-specific operation data.

Encoding for version-specific operation receipts.

Encoding that mixes an operation data and its receipt.

The Validation passes in which an operation can appear. For instance [0] if it only belongs to the first pass. An answer of [] means that the operation is ill-formed and cannot be included at all.

Basic ordering of operations. compare_operations op1 op2 means that op1 should appear before op2 in a block.

A functional state that is transmitted through the steps of a block validation sequence. It must retain the current state of the store (that can be extracted from the outside using current_context, and whose final value is produced by finalize_block). It can also contain the information that must be remembered during the validation, which must be immutable (as validator or baker implementations are allowed to pause, replay or backtrack during the validation process).

Access the context at a given validation step.

Checks that a block is well formed in a given context. This function should run quickly, as its main use is to reject bad blocks from the chain as early as possible. The input context is the one resulting of an ancestor block of same protocol version. This ancestor of the current head is guaranteed to be more recent than `last_allowed_fork_level`.

The resulting `validation_state` will be used for multi-pass validation.

The first step in a block validation sequence. Initializes a validation context for validating a block. Takes as argument the Block_header.t to initialize the context for this block. The function precheck_block may not have been called before begin_application, so all the check performed by the former must be repeated in the latter.

Initializes a validation context for constructing a new block (as opposed to validating an existing block). When the protocol_data argument is specified, it should contains a 'prototype' of a the protocol specific part of a block header, and the function should produce the exact same effect on the context than would produce the validation of a block containing an "equivalent" (but complete) header. For instance, if the block header usually includes a signature, the header provided to begin_construction should includes a faked signature.

Called after begin_application (or begin_construction) and before finalize_block, with each operation in the block.

The last step in a block validation sequence. It produces the context that will be used as input for the validation of its successor block candidates.

The list of remote procedures exported by this implementation

Initialize the context (or upgrade the context after a protocol amendment). This function receives the context resulting of the application of a block that triggered the amendment. It also receives the header of the block that triggered the amendment.