package tezos-protocol-015-PtLimaPt

  1. Overview
  2. Docs
package tezos-protocol-015-PtLimaPt
Legend:
Library
Module
Module type
Parameter
Class
Class type
type dissection_chunk = {
  1. state_hash : Sc_rollup_repr.State_hash.t option;
  2. tick : Sc_rollup_tick_repr.t;
}

A dissection chunk is made of a state hash (that could be None, see invariants below), and a tick count.

type game_state =
  1. | Dissecting of {
    1. dissection : dissection_chunk list;
      (*

      dissection, a list of states with tick counts. The current player will specify, in the next move, a tick count that indicates the last of these states that she agrees with.

      *)
    2. default_number_of_sections : int;
      (*

      default_number_of_sections is the number of sections a disection should contain in the more general case where we still have a high enough number of disputed ticks.

      *)
    }
    (*

    When the state is Dissecting, both player are still dissecting the commitment to find the tick to refute.

    *)
  2. | Final_move of {
    1. agreed_start_chunk : dissection_chunk;
    2. refuted_stop_chunk : dissection_chunk;
    }
    (*

    When the state is Final_move, either Alice or Bob already played an invalid proof.

    The other player will have a chance to prove that the refuted_stop_state is valid. If both players fail to either validate or refute the stop state, the current game state describes a draw situation. In the same way, the draw can be described by the situation where the two players manage to validate or refute the stop state.

    *)

Describes the current state of a game.

val game_state_equal : game_state -> game_state -> bool
type t = {
  1. turn : player;
  2. inbox_snapshot : Sc_rollup_inbox_repr.history_proof;
  3. level : Raw_level_repr.t;
  4. pvm_name : string;
  5. game_state : game_state;
}

A game is characterized by:

  • turn, the player that must provide the next move.
  • inbox_snapshot, a snapshot of the inbox state at the moment the game is created. This is only used when checking Input_step and Blocked_step proofs; it makes the proofs easier to create--- otherwise they would have a 'moving target' because the actual inbox may be updated continuously.
  • level, the inbox level of the commitment the game is refuting. This is only used when checking Blocked_step proofs---the proof will show that the next message available in inbox_snapshot is at level, so shouldn't be included in this commitment.
  • pvm_name identifies the PVM used in this rollup. It is useful to have here so we can check that the proof provided in a refutation is of the correct kind.
  • game_state, the current state of the game, see game_state for more information.

Invariants: -----------

  • dissection must contain at least 2 values (normally it will be 32 values, but smaller if there isn't enough space for a dissection that size. The initial game dissection will be 3 values except in the case of a zero-tick commit when it will have 2 values.)
  • the first state hash value in dissection must not be None
  • inbox_snapshot never changes once the game is created
val equal : t -> t -> bool

equal g1 g2 returns true iff g1 is equal to g2.

val opponent : player -> player

Return the other player

val player_equal : player -> player -> bool
OCaml

Innovation. Community. Security.

GitHub Discord Twitter Peertube RSS
About
Changelog Releases Industrial Users Academic Users Why OCaml
Ecosystem
Packages Community Events OCaml Planet Jobs
Resources
Install OCaml Get Started Platform Tools Language Manual Standard Library API Books Exercises Papers OCaml Playground Logo
Policies
Carbon Footprint Governance Privacy Code of Conduct