package tezos-protocol-015-PtLimaPt

  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-16.0.tar.gz
sha256=ad9e08819871c75ba6f4530b125f7d157799398e4d77a1e6bfea9d91ff37ff55
sha512=c5dc4d40cc09bc6980fbbdb5c2e105bf4252cf9cfcb2b49660b0ebe4dc789f6709ec3b3bf2f87d81580d3eed9521eeb1c960f24d9b14eb0285aaba1f84d10a9b

doc/tezos-protocol-015-PtLimaPt.raw/Tezos_raw_protocol_015_PtLimaPt/Sc_rollup_proof_repr/index.html

Module Tezos_raw_protocol_015_PtLimaPt.Sc_rollup_proof_reprSource

A refutation game proof is required as part of the final move in a game.

This proof is basically a combination of a PVM proof (provided by each implementation of the PVM signature) and an input proof. To check the proof we must check each part separately and then also check that they match on the two points where they touch:

  • the input_requested of the PVM proof should match the starting point of the input proof ;
  • the input_given of the PVM proof should match the output message of the input proof.

It is also often the case that the PVM proof has No_input_required for its input_requested and None for its input_given. If this is the case, we don't need the input proof at all and the input_proof parameter in our proof should be None.

Sourcetype reveal_proof =
  1. | Raw_data_proof of string
    (*

    The existence of reveal for a given hash when the input_requested is the Needs_for_reveal.

    *)

The proof that a reveal is valid.

A PVM proof pvm_step is combined with an input_proof to provide the proof necessary to validate a single step in the refutation game.

If the step doesn't involve any input, proof_input_requested pvm_step and proof_input_given pvm_step will be No_input_required and None respectively, and in this case inbox should also be None.

In the case that input is involved, input_proof is either:

  • a proof of the next inbox message available from the inbox after a given location; this must match up with pvm_step to give a valid refutation proof ; or
  • a proof of a reveal satisfiability.
Sourcetype input_proof =
  1. | Inbox_proof of {
    1. level : Raw_level_repr.t;
    2. message_counter : Tezos_protocol_environment_015_PtLimaPt.Z.t;
    3. proof : Sc_rollup_inbox_repr.serialized_proof;
    }
  2. | Reveal_proof of reveal_proof
Sourcetype t = {
  1. pvm_step : Sc_rollups.wrapped_proof;
  2. input_proof : input_proof option;
}
Sourcetype Tezos_protocol_environment_015_PtLimaPt.Error_monad.error +=
  1. | Sc_rollup_proof_check of string
Sourcetype Tezos_protocol_environment_015_PtLimaPt.Error_monad.error +=
  1. | Sc_rollup_invalid_serialized_inbox_proof

The state hash of the machine before the step. This must be checked against the value in the refutation game as well as checking the proof is valid.

The state hash of the machine after the step. This must be checked against the value in the refutation game as well as checking the proof is valid.

Check the validity of a proof.

This function requires a few bits of data (available from the refutation game record in the storage):

  • a snapshot of the inbox, that may be used by the input proof ;
  • the inbox level of the commitment, used to determine if an output from the input proof is too recent to be allowed into the PVM proof ;
  • the pvm_name, used to check that the proof given has the right PVM kind.

It also returns the optional input executed during the proof and the input_request for the state at the beginning of the proof.

Sourcemodule type PVM_with_context_and_state = sig ... end

produce pvm_and_state inbox_context inbox_history commit_level will construct a full refutation game proof out of the state given in pvm_and_state. It uses the inbox if necessary to provide input in the proof. If the input is above or at commit_level it will block it, and produce a proof that the PVM is blocked. If the input requested is a reveal the proof production will also fail.

This will fail if any of the context, inbox_context or inbox_history given don't have enough data to make the proof. For example, the 'protocol implementation' version of each PVM won't be able to run this function. Similarly, the version of the inbox stored in the L1 won't be enough because it forgets old levels.

This uses the name in the pvm_and_state module to produce an encodable wrapped_proof if possible. See the wrap_proof function in Sc_rollups.