package octez-shell-libs

  1. Overview
  2. No Docs
Octez shell libraries

Install 

dune-project
 Dependency

www.tezos.com Edit opam file Versions (5)

Authors

  1. T
    Tezos devteam

Maintainers

  1. C
    contact@tezos.com

Sources

tezos-18.1.tar.gz
sha256=aa2f5bc99cc4ca2217c52a1af2a2cdfd3b383208cb859ca2e79ca0903396ca1d
sha512=d68bb3eb615e3dcccc845fddfc9901c95b3c6dc8e105e39522ce97637b1308a7fa7aa1d271351d5933febd7476b2819e1694f31198f1f0919681f1f9cc97cb3a

doc/octez-shell-libs.shell/Tezos_shell/Block_validator/index.html

Module Tezos_shell.Block_validatorSource

This module is the main entry point to valide blocks and protocols.

Sourcetype t
Sourcetype new_block = {
  1. block : Tezos_store.Store.Block.t;
    (*

    The block itself.

    *)
  2. resulting_context_hash : Tezos_base.TzPervasives.Context_hash.t;
    (*

    The context hash resulting of block's application.

    It may be the same one as contained in its header depending on the protocol expected semantics.

    *)
}

Type of a validated block

create limits ddb bvp start_testchain creates a Block_validator.

  • limits contains various timeout limits.
  • ddb is used to commit a block on the storage and get the state of the chain for which the block is submitted to validation.
  • bvp is an instance of the Block_validator_process. bvp is a proxy between the shell and the validation part related to the economic protocol (See Block_validator_process).
  • start_testchain if set to true allows to run the testchain.

This function is not supposed to fail. It is implemented this way because of the interface implemented by the Worker module.

Sourceval validate : t -> ?canceler:Lwt_canceler.t -> ?peer:Tezos_base.P2p_peer.Id.t -> ?notify_new_block:(new_block -> unit) -> ?precheck_and_notify:bool -> Distributed_db.chain_db -> Tezos_base.TzPervasives.Block_hash.t -> Tezos_base.Block_header.t -> Tezos_base.Operation.t list list -> block_validity Lwt.t

validate ?precheck_and_notify validator ddb hash header ops validates a block header ops of hash hash. It is a no-op in the following cases:

  • If the block has already been validated.
  • If the block level is before the savepoint

Otherwise it calls the Block_validator_process process associated to the current validator.

  • canceler is trigerred when the validation of a block fails.
  • peer is the peer which sent the block.

If the validation succeeded it processes as follows:

1. The ddb commits the block on the storage.

2. If the next block requires a switch of protocol, it tries to fetch and precompile the next protocol.

3. Call notify_new_block with the committed block.

An error is raised if the validation failed or if the block was already known as invalid. However, if the first validation attempt failed because the protocol was missing, it tries to fetch and download the protocol before trying to validate the block a second time.

Sourceval preapply : t -> ?canceler:Lwt_canceler.t -> Tezos_store.Store.chain_store -> predecessor:Tezos_store.Store.Block.t -> timestamp:Tezos_base.Time.Protocol.t -> protocol_data:bytes -> Tezos_base.Operation.t list list -> (Tezos_base.Block_header.shell_header * Tezos_base.TzPervasives.error Tezos_shell_services.Preapply_result.t Tezos_base.TzPervasives.trace) Tezos_base.TzPervasives.tzresult Lwt.t

preapply validator canceler chains_store predecessor timestamp protocol_data operations creates a new block and returns it. It may call the Block_validator_process process associated to the current validator. If the preapply is a succeeded, the application resulted is cached to avoid re-apply the block if the next call block validation, through validate, targets the same block.

An error is raised if the pre-apply failed. However, if the first pre-apply attempt failed because the protocol was missing, it tries to fetch and download the protocol before trying to pre-apply the block a second time.

Sourceval fetch_and_compile_protocol : t -> ?peer:Tezos_base.P2p_peer.Id.t -> ?timeout:Tezos_base.Time.System.Span.t -> Tezos_base.TzPervasives.Protocol_hash.t -> Tezos_protocol_updater.Registered_protocol.t Tezos_base.TzPervasives.tzresult Lwt.t
Sourceval context_garbage_collection : t -> Tezos_context_ops.Context_ops.index -> Tezos_base.TzPervasives.Context_hash.t -> gc_lockfile_path:string -> unit Tezos_base.TzPervasives.tzresult Lwt.t

context_garbage_collection bv index chain_store context_hash ~gc_lockfile_path moves the contexts below the give context_hash from the upper layer to the lower layer. For full and rolling nodes, this is considered as a garbage collection. When a garbage collection occurs in another process, a lock, located at gc_lockfile_path, is taken to ensure synchronous GC calls.

context_split bv index finishes and then starts a new chunk in the context storage layout. This aims to be called at the dawn of each cycle, to improve the disk footprint when running a garbage collection.

Sourceval shutdown : t -> unit Lwt.t
Sourceval running_worker : unit -> t