package tezos-protocol-010-PtGRANAD

  1. Overview
  2. Docs
Tezos/Protocol: economic-protocol definition

Install 

dune-project
 Dependency

www.tezos.com Readme Edit opam file Versions (8)

Authors

  1. T
    Tezos devteam

Maintainers

  1. C
    contact@tezos.com

Sources

tezos-17.3.tar.gz
sha256=7062cd57addd452852598a2214ade393130efa087b99068d53713bdf912b3680
sha512=08e4091144a03ce3c107fb91a66501bd8b65ca3278917c455a2eaac6df3e108ade63f6ab8340a4bb152d60f404326e464d0ec95d26cafe8e82f870465d24a5fc

doc/tezos-protocol-010-PtGRANAD.raw/Tezos_raw_protocol_010_PtGRANAD/Baking/index.html

Module Tezos_raw_protocol_010_PtGRANAD.BakingSource

Sourcetype Tezos_protocol_environment_010_PtGRANAD.Error_monad.error +=
  1. | Invalid_fitness_gap of int64 * int64
Sourcetype Tezos_protocol_environment_010_PtGRANAD.Error_monad.error +=
  1. | Timestamp_too_early of {
    1. minimal_time : Alpha_context.Timestamp.t;
    2. provided_time : Alpha_context.Timestamp.t;
    3. priority : int;
    4. endorsing_power_opt : int option;
    }
Sourcetype Tezos_protocol_environment_010_PtGRANAD.Error_monad.error +=
  1. | Invalid_endorsement_slot of int
Sourcetype Tezos_protocol_environment_010_PtGRANAD.Error_monad.error +=
  1. | Unexpected_endorsement_slot of int

minimal_time ctxt priority pred_block_time returns the minimal time, given the predecessor block timestamp pred_block_time, after which a baker with priority priority is allowed to bake in principle, that is, assuming the block will contain enough endorsements.

check_timestamp ctxt priority pred_timestamp verifies that the timestamp is coherent with the announced baking slot.

For a given level computes who has the right to include an endorsement in the next block. The result can be stored in Alpha_context.allowed_endorsements

Check that the operation was signed by a the delegate allowed to endorse at the given slot and at the level specified by the endorsement. The slot should be the smallest among the delegate's slots.

Sourceval baking_reward : Alpha_context.context -> block_priority:int -> included_endorsements:int -> Alpha_context.Tez.t Tezos_protocol_environment_010_PtGRANAD.Error_monad.tzresult

Returns the baking reward calculated w.r.t a given priority p and a number e of included endorsements

Returns the endorsing reward calculated w.r.t a given priority.

baking_priorities ctxt level is the lazy list of contract's public key hashes that are allowed to bake for level.

first_baking_priorities ctxt ?max_priority contract_hash level is a list of priorities of max ?max_priority elements, where the delegate of contract_hash is allowed to bake for level. If ?max_priority is None, a sensible number of priorities is returned.

check_signature ctxt chain_id block id check if the block is signed with the given key, and belongs to the given chain_id

Sourceval check_header_proof_of_work_stamp : Alpha_context.Block_header.shell_header -> Alpha_context.Block_header.contents -> int64 -> bool

Checks if the header that would be built from the given components is valid for the given difficulty. The signature is not passed as it is does not impact the proof-of-work stamp. The stamp is checked on the hash of a block header whose signature has been zeroed-out.

verify if the proof of work stamp is valid

check if the gap between the fitness of the current context and the given block is within the protocol parameters

Since Emmy+

A block is valid only if its timestamp has a minimal delay with respect to the previous block's timestamp, and this minimal delay depends not only on the block's priority but also on the number of endorsement operations included in the block.

In Emmy+, blocks' fitness increases by one unit with each level.

In this way, Emmy+ simplifies the optimal baking strategy: The bakers used to have to choose whether to wait for more endorsements to include in their block, or to publish the block immediately, without waiting. The incentive for including more endorsements was to increase the fitness and win against unknown blocks. However, when a block was produced too late in the priority period, there was the risk that the block did not reach endorsers before the block of next priority. In Emmy+, the baker does not need to take such a decision, because the baker cannot publish a block too early.

Given a block priority and a number of endorsement slots (given by the `endorsing_power` argument), it returns the minimum time at which the next block can be baked.