package tezos-protocol-014-PtKathma
Install
Dune Dependency
Authors
Maintainers
Sources
sha256=43723d096307603703a1a89ed1b2eb202b365f5e7824b96b0cbf813b343a6cf7
sha512=b2a637f2e965000d3d49ad85277ca24d6cb07a1a7cf2bc69d296d8b03ad78c3eaa8e21e94b9162e62c2e11649cd03bc845b2a3dafe623b91065df69d47dc8e4f
doc/tezos-protocol-014-PtKathma.raw/Tezos_raw_protocol_014_PtKathma/Sc_rollup_proof_repr/index.html
Module Tezos_raw_protocol_014_PtKathma.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 inbox 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_requestedof the PVM proof should match the starting point of the inbox proof ;
- the
input_givenof the PVM proof should match the output message of the inbox 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 inbox proof at all and the inbox parameter in our proof should be None.
A PVM proof pvm_step is combined with an inbox 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, inbox is a proof of the next message available from the inbox after a given location; this must match up with pvm_step to give a valid refutation 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.
val valid :
Sc_rollup_inbox_repr.t ->
Raw_level_repr.t ->
pvm_name:string ->
t ->
(bool, Tezos_protocol_environment_014_PtKathma.Error_monad.error)
Tezos_protocol_environment_014_PtKathma.Pervasives.result
Tezos_protocol_environment_014_PtKathma.Lwt.tCheck 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, used by the
inboxproof ;
- the inbox level of the commitment, used to determine if an output from the
inboxproof 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.
val produce :
(module PVM_with_context_and_state) ->
Sc_rollup_inbox_repr.t ->
Raw_level_repr.t ->
(t, Tezos_protocol_environment_014_PtKathma.Error_monad.error)
Tezos_protocol_environment_014_PtKathma.Pervasives.result
Tezos_protocol_environment_014_PtKathma.Lwt.tproduce pvm_and_state inbox 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.
This will fail if the context given doesn't have enough of the state to make the proof. For example, the 'protocol implementation' version of each PVM won't be able to run this function.
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.