package tezos-protocol-alpha

  1. Overview
  2. Docs
Legend:
Library
Module
Module type
Parameter
Class
Class type
type dissection_chunk = Sc_rollup_dissection_chunk_repr.t
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. dal_snapshot : Dal_slot_repr.History.t;
  4. start_level : Raw_level_repr.t;
  5. inbox_level : Raw_level_repr.t;
  6. game_state : game_state;
}

A game is characterized by:

  • refuter_commitment_hash, the hash of the commitment of the player that has initiated the game.
  • defender_commitment_hash, the hash of the commitment of the player that is tentatively refuted.
  • 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.
  • dal_snapshot, a snapshot of the DAL's confirmed slots history at the moment the game is created. In fact, since the confirmed slots history at initialization would likely evolve during the game, we need a (fixed) reference w.r.t. which Dal input proofs would be produced and verified if needed.
  • 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.
  • 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 and dal_snapshot never change 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.